[DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)
mal at egenix.com
Mon Jan 21 12:57:22 CET 2008
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
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.
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
More information about the DB-SIG