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

[Federico Di Gregorio]

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. 

federico

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog at debian.org
INIT.D Developer                                           fog at initd.org
 When people say things are a lot more complicated than that, they
  means they're getting worried that they won't like the truth.
                                                    -- Granny Weatherwax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio
	firmata digitalmente
Url : http://mail.python.org/pipermail/db-sig/attachments/20080121/8661bd0d/attachment.pgp