As discussed here last week, libpqxx has been extended to allow
programmer-selectable "qualities of service" for transaction classes,
ranging from unprotected "transactions" (which only pretend to be a
transaction to the library, but don't start one on the backend), through
plain backend transactions, to the new "robust" transaction class.
Don't expect the robust transaction class to fail less frequently than
plain transactions; they're more complex so they would be more vulnerable
because of the slowdown alone. But if you lose your connection while
committing a robust transaction, and the frontend has no way of knowing
whether the backend actually committed it or not, it will transparently
attempt to reconnect to the database and check for a "log" record that it
left in a dedicated log table as the transaction began. Since this
insertion was part of the same backend transaction, the presence of the
record at this point in time should reliably indicate what happened to
the transaction (if it was aborted, obviously the record won't be there
either). The class will then proceed as with a normal commit or
connection failure, reducing indeterminacy to the case where no new
connection could be made.
I'm aware that this mechanism can still fail, but hopefully it will
minimize the in-doubt window. I've written a few simple tests for the
"all's well" case, and they ran successfully the first time. Is there
anyone out there willing to give this a good test run, or write new test
programs?
Find it at http://members.ams.chello.nl/j.vermeulen31/proj-libpqxx.html
as usual. I'm tired, my wrists hurt, I'm going to sleep. :-)
Jeroen
