Re: PATCH: two phase commit

Il giorno lun, 21/01/2008 alle 19.31 +0900, James Henstridge ha scritto:
> > I personally would prefer clean access to the PostgreSQL API rather
> than
> > having the driver impose smarts here, thinking it knows best and
> locking the
> > connection on me.
> 
> Well, you can always issue whatever you want if you put the connection
> in autocommit mode and issue the statements directly.  This API isn't
> going to affect that.
> 
> If providing a more restricted API allows us to standardise it, then I
> think that'd be worth it.  I've sent a mail to the db-sig list with a
> proposal for such an API, based on the database adapters I've seen,
> and documentation on various databases' 2PC APIs.

I think Stuart's arguments should be taken in consideration (as I wrote
on DBSIG). Now, usually thetimes to reach agreement on DBSIG are veeery
long so let's try to sketch the "right" API here too. I'll call the
methods with an xa_ prefix, but this is temporary.

conn.xa_begin(id, keep=false)
        Explicitly begin a new transaction and mark it a two-phase in
        the connection object. If 'keep' is true the transaction will
        never be implicitly aborted by psycopg, else psycopg will
        implicitly abort the transaction on connection close and/or
        dealloc.

conn.xa_prepare()
        Execute the first step of a two-phase commit. Raise a meaningful
        exception of the transaction can't be completed.

conn.commit()
conn.rollback()
        Modified to execute the second step of a two-phase commit. Note
        that it is an error (should raise) to call commit() on a
        connection marked as two-phase without first calling
        xa_prepare(). This is to avoid logical errors where you think it
        is two-phase but forget to check by preparing it.

Note that this API makes impossible to commit or rollback an arbitrary
prepared transaction. For that you'll need to issue the appropriate SQL
in from outside a transaction (isolation_level 0). I don't see that as a
drawback.

Also this locks the connection to the prepared transaction so the only
way to "detach" the transaction and let it live is to use keep=true and
then close the connection. Do we need a xa_detach() method? I think not,
right now.

federico

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                [email protected]
INIT.D Developer                                           fog-NGVKUo/i/[email protected]
  We should forget about small efficiencies, say about 97% of the
   time: premature optimization is the root of all evil.    -- D.E.Knuth

_______________________________________________
Psycopg mailing list
Psycopg-IAPFreCvJWPBWskQ1e/[email protected]
http://lists.initd.org/mailman/listinfo/psycopg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHlHh+vcCgrgZGjesRAjIoAKCs8vzSH9Los92aK8svr8M8IrH9cACfd48s
Ro54GXkIwoM9JSNW1CfIHtw=
=Xc+C
-----END PGP SIGNATURE-----