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. -- Daniele [1]: http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/jdbc/pgjdbc/org/postgresql/xa/RecoveredXid.java?rev=1.3&content-type=text/x-cvsweb-markup _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
