On 21/01/2008, Federico Di Gregorio <[EMAIL PROTECTED]> wrote:
>
> Il giorno lun, 21/01/2008 alle 20.09 +0900, James Henstridge ha scritto:
> > > IMHO, it should raise an error if the transaction was started for
> > > two-phase. Otherwise I don't see any reason for (1).
> >
> > I disagree here. If a problem is detected early in the transaction,
> > calling prepare() before rollback() on the other members of the global
> > transaction is a waste of effort.
> >
> > As for commit(), the transaction manager can use one-phase commit for
> > the last resource without integrity problems. I don't see much value
> > in preventing this optimisation.
>
> I agree on rollback(), not on commit(). If the transaction manager wants
> to use one-phase it should do that explicitly. Allowing to call commit
> on a two-phase transaction without first preparing it is prone to errors
> and can lead to subtle errors like depending on it creating a "standard"
> transaction on some backends and not on others.
MySQL appears to have a special API for performing a one-phase commit
of an XA transaction:
XA COMMIT xid ONE PHASE
Perhaps an argument to xa_commit() would be appropriate here?
connection.xa_commit(onephase=True)
Without the argument, the commit would be considered to be a
ProgrammingError. That would reduce the chance of programmer error
leading to data corruption.
James.
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
