On Sat, Sep 25, 2010 at 12:04 AM, Daniele Varrazzo <daniele.varra...@gmail.com> wrote: > On Fri, Sep 24, 2010 at 9:48 AM, M.-A. Lemburg <m...@egenix.com> wrote: > >> I'd also look around to check how other tools that interoperate with >> PG in two-phase commits handle this. XA is a widely used standard >> in the industry, so I assume the problem must have popped up >> elsewhere as well. > > MySQL uses a XA model, so the mapping is direct. Other high profile > databases hide the commands they use under tons of APIs and I've not > been able to find implementation details. > > I've found instead the JDBC implementation of the XA - PG mapper [1]: > it is probably a good idea to use the same format to allow some form > of interoperation between tools. They use str(format_id) + '_' + > Base64(gtrid) + '_' + Base64(bqual) and on recover they refuse to work > on anything that doesn't follow this model. I don't agree on the > latter point because I think the driver should allow the user to > leverage everything the database permits, so I will probably find a > way to parse back a generic string into a XID. But I guess this is an > implementation detail better discussed on the psycopg mailing lists. > > Thank you very much. Have a nice weekend.
When writing the TPC additions for the spec, I did take PostgreSQL into account (I thought I'd have time to write the psycopg2 implementation back then). The reasoning for using the three part identifiers was that the XA-style identifiers were quite common and it was easier to losslessly encode the three part identifiers as a string than vice versa. The spec should allow you to manage identifiers that don't match your mapping though. The user can only get references to transaction ID objects via method calls on the connection. So while transaction IDs are required to provide tuple like behaviour, the adapter doesn't have to use actual tuple objects. A custom object type could easily be used here to round trip the foreign IDs between tpc_recover() and tpc_commit()/tpc_abort(). James. _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
