Re: PATCH: two phase commit
Federico Di Gregorio <fog-NGVKUo/i/[email protected]>
| Newsgroups | gmane.comp.python.db.psycopg.devel |
|---|---|
| Organization | initd.org |
| Message-ID | <[email protected]> |
Il giorno lun, 21/01/2008 alle 11.31 +0900, James Henstridge ha scritto: > > 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. Agreed. Then I'll start with a single prepare_current_transaction() method that "locks" the connection (i.e., every other operation raise an exception) untill commit() or rollback() are called. federico -- Federico Di Gregorio http://people.initd.org/fog Debian GNU/Linux Developer [email protected] INIT.D Developer fog-NGVKUo/i/[email protected] Se il sesso non ammacca è una patacca (!) -- Camilla Carotina _______________________________________________ Psycopg mailing list Psycopg-IAPFreCvJWPBWskQ1e/[email protected] http://lists.initd.org/mailman/listinfo/psycopg
signature.asc
(application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHlGExvcCgrgZGjesRAgJ+AJ9oinvUzb8zXLZwtqNfsVb9nQOtEwCeKtaH mWm2R7o1Vr+ux6Rv58E9Hzs= =BObC -----END PGP SIGNATURE-----