On 2008-01-21 12:31, Stuart Bishop wrote: > M.-A. Lemburg wrote: > >> A connection drop should always trigger an implicit rollback on the >> server side, so I'm not sure how and where you'd keep the required >> state to continue processing the transaction in case the connection >> is reestablished. > > With PostgreSQL, when you PREPARE TRANSACTION all state is flushed to disk. > If your network drops before you can commit or even if your server catches > fire you can still reconnect later and commit the transaction (provided your > disks survive). > > As an example, lets say you are dealing with three data stores and an > exception is raised in the second phase whilst committing the 2nd data store. > > If the transaction on the 3rd data store is rolled back then you can only > recover by somehow rolling back the transaction on the 1st and maybe 2nd > data store. Given this is probably a multi user environment this may well > involve data loss. > > If the transaction on the 3rd data store is not rolled back, then you can > recover if the problem was transient by simply retrying the outstanding > commits once the network glitch or whatever has been fixed. All you need are > the transaction ids you used (and why meaningful transaction ids can make > your life easier at 2am).
Thanks for the explanations. I was actually thinking of the connection between the TM and the RM (the database backend). The typical behavior of a TM is to cancel the ongoing two-phase commit transaction if an RM becomes unavailable. However, I can see your point. If the data stays on the database server and can be addressed via the XID, then a dropped connection wouldn't hurt all that much. Then again: how do you tell the database to forget about the data stored for an XID ? XA has an xa_forget() API for this, but I'm not sure whether this is expected to also work across TM-RM reconnects or whether the TM is actually expected to retry the reconnect at all. Im MQ Series apps, the typical behavior would be to put the data back on the queue and retry the whole transaction at some later point. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 21 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
