[DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

[Stuart Bishop]

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).

-- 
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://mail.python.org/pipermail/db-sig/attachments/20080121/090adebf/attachment.pgp