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 <[EMAIL PROTECTED]> http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
