> This scares the hell out of me. How do you know whether the old
> session committed your transaction, but the connection died just before
> it could tell you so? libpqxx is the very LAST place in the chain that
> is qualified to undertake the task of error recovery.
I guess you're right in that the best place to solve these problems (in the
absence of two-phase commit) is ultimately within the client. What libpqxx
tries to do is to encourage people to write restartable transactions, and
provide a reusable solution to the problem.
Your point about TCP is well taken--the big assumption currently underlying
the libpqxx mechanism is that sending the final commit and closing the
connection are atomic and both sides of the connection will have the same
idea of whether it failed or succeeded. You are right in that this is a
risk.
Even so, compensating for this seems doable, with the major stumbling block
probably being garbage collection on transaction state information.
Admittedly this goes beyond a mere language binding, but it seems to me
that this could be a helpful tool to the developer. After all the problem
exists whether it's left for the client to deal with or not.
> In any case, I do not think that libpq or libpqxx can or should try to
> hide this problem from the client.
Hiding it completely is impossible, but I'd like to help the client in
trying to cope with it. And I'm willing to invest some time in trying to
make that work because IMHO the value to users could be considerable.
Jeroen