Re: PATCH: two phase commit

On 18/01/2008, Federico Di Gregorio <fog-NGVKUo/i/[email protected]> wrote:
> > I did take a look for existing adapters for ideas and found two others:
> >
> > The kinterbasdb module adds a prepare() method to the connection
> > object.  After calling this method, the standard commit() and
> > rollback() methods can be used to perform the second phase of the
> > commit.  This would be implementable in psycopg2, with the following
> > caveats:
> >  1. we'd need to be able to generate unique transaction identifiers.
> >  2. it provides no way to commit a transaction prepared with another connection.
>
> First of all we can't user prepare() because that should be reserved for
> prepared statements. prepare_transaction() or even the very explicit
> prepare_current_transaction() (that is exactly what the method does) are
> fine. The ability to generate XID is undubtely useful.
>
> The question is, we want to "lock" the connection untill the current
> prepared transaction is commited or we want to give the client the
> ability to set aside prepared transactions and execute them from a
> different connection? If nobody need the second one the first option is
> "safe"; you can even abort the currently prepared transaction on object
> dealloc.

Yep.  The more limited API would handle pretty much everything I need to.

I think the primary use case for committing/rolling back a transaction
from a different connection is recovery, which may be out of scope for
a common 2PC API for Python database adapters.

> federico
>
> p.s. did you find M.A.L. answer confusing? I did.. :/

A bit.  I'll see how the thread develops.

James.