Обсуждение: XA Xid to PostgreSQL transaction ID

Hello,

I have implemented two-phase commit into the Python PostgreSQL driver
psycopg2. As the Python DBAPI is XA inspired, the transaction IDs it
demands to handle are composed by triples (format_id, gtrid, bqual).
PostgreSQL instead asks for plain strings as transaction IDs.

I'd like to implement the mapping algorithm exactly the way the JDBC
driver does, as it would allow tools written in Python to interoperate
to ones written in Java and understand each other the XA components of
the transaction IDs.

I've found the implementation of the mapping in JDBC in [1] and I've
reimplemented it. I'd like to double check that the results actually
match.

As a test I have in the test suite the triple (42, 'gtrid', 'bqual')
is converted into the string '42_Z3RyaWQ=_YnF1YWw=': I'd like to know,
if possible, if this is the same result obtained by the JDBC driver.
Alternatively, if you can provide me one or more known triple ->
string transformation examples, I can check them and add them to the
test suite.

Thank you very much. Best regards.


-- Daniele


[1] http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/jdbc/pgjdbc/org/postgresql/xa/RecoveredXid.java?rev=1.2

On Thu, 14 Oct 2010, Daniele Varrazzo wrote:

> I have implemented two-phase commit into the Python PostgreSQL driver
> psycopg2. As the Python DBAPI is XA inspired, the transaction IDs it
> demands to handle are composed by triples (format_id, gtrid, bqual).
> PostgreSQL instead asks for plain strings as transaction IDs.
>
> I'd like to implement the mapping algorithm exactly the way the JDBC
> driver does, as it would allow tools written in Python to interoperate
> to ones written in Java and understand each other the XA components of
> the transaction IDs.
>

I'm not sure how valuable that will really be.  This information should
really only be useful to a transaction manager(TM), so I'm not sure what
interoperability would gain.  No TM is going to start a Java transaction
and later try to recover it using a Python client (or the other way
around).

> As a test I have in the test suite the triple (42, 'gtrid', 'bqual')
> is converted into the string '42_Z3RyaWQ=_YnF1YWw=': I'd like to know,
> if possible, if this is the same result obtained by the JDBC driver.
> Alternatively, if you can provide me one or more known triple ->
> string transformation examples, I can check them and add them to the
> test suite.

Yes, this is the same result as the JDBC driver.

Kris Jurka

On Tue, Oct 19, 2010 at 8:06 PM, Kris Jurka <books@ejurka.com> wrote:

>> I'd like to implement the mapping algorithm exactly the way the JDBC
>> driver does, as it would allow tools written in Python to interoperate
>> to ones written in Java and understand each other the XA components of
>> the transaction IDs.
>
> I'm not sure how valuable that will really be.  This information should
> really only be useful to a transaction manager(TM), so I'm not sure what
> interoperability would gain.  No TM is going to start a Java transaction and
> later try to recover it using a Python client (or the other way around).

Yes, it may not happen that such tool exist. But because we have the
same xid <-> str mapping problem the jdbc driver has had, seems
reasonable to solve it the same way. On the other hand the jdbc
solution has the shortcoming of producing not readable strings: I
don't know either if this is a valuable property. I will discuss with
the other developers about the two possibilities.

>> As a test I have in the test suite the triple (42, 'gtrid', 'bqual')
>> is converted into the string '42_Z3RyaWQ=_YnF1YWw=': I'd like to know,
>> if possible, if this is the same result obtained by the JDBC driver.

> Yes, this is the same result as the JDBC driver.

Thank you very much for the information.

Best regards,

-- Daniele