I've just added some plumbing to libpqxx that checks for lost
connections while a transaction is being committed. As discussed here
last week, in that situation there is no way to tell whether the
transaction really succeeded or not and the only things a front-end
library can do are to (i) warn the user, and (ii) not retry the
transaction.
At some piont I would like to go to the next stage and try to deal with
these situations as soon as the connection is re-established. I could
do this by setting up a "user-level transaction log" table, but I do
expect that to be a significant performance drain and source of
complexity.
Alternatively, perhaps it would be possible to expose a minimal query
interface to the transaction log, so the front-end would have a fighting
chance of reconnecting and figuring out what happened to its last
transaction (committed / aborted / don't remember). I don't know
enough about the back-end to see if this would be feasible, and I do
realize it would probably require a change to the frontend-backend
interface (like maybe sending a transaction ID back as a result for a
BEGIN WORK statement, and adding a "check transaction" internal query).
But a useful thing to keep in mind for the future perhaps?
Find the new code at
http://members.ams.chello.nl/j.vermeulen31/proj-libpqxx.html
Jeroen
