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

[Stuart Bishop]

M.-A. Lemburg wrote:

> Mixing one-phase and two-phase commits sounds like mixing two
> concepts that don't belong together, IMHO.
> 
> It would be too easy for an application to issue a .commit()
> somewhere and thereby breaking the whole two phase commit
> idea.

I'm not sure this is worth worrying about - applications can screw things up
right now by issuing COMMITs or ROLLBACKS when shouldn't.

> I'd rather like to see the two concepts well separated and
> exceptions raised if you try to mix them.
> 
> After all, you could still open a second connection if you
> need one phase transactions for some other purpose.

At the start of a transaction, you might not know that only one of your data
stores is going to be modified. Two phase commit imposes an overhead which
can be avoided if only one of your data stores turns out to need changes. I
believe this is why in PostgreSQL you declare you are using 2PC at the end
of your transaction and why MySQL offers you the XA COMMIT xid ONE PHASE option.

-- 
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/625ae5f0/attachment.pgp