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

[James Henstridge]

On 21/01/2008, Federico Di Gregorio <fog at initd.org> 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.