Re: jdbc xa patches

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Michael Allman <msa(at)allman(dot)ms>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: jdbc xa patches
Date: 2005-07-27 05:27:57
Message-ID: 42E71B5D.5000609@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Michael Allman wrote:

> First, I'm assuming that any general release of the JDBC driver with XA
> support will make it clear up front that it requires Postgres 8.1.

Sure, but not everyone reads documentation before posting "problems" to
the list.

> With that in mind, if some mortal is foolish enough to attempt to
> prepare a transaction on an unsupported backend, executeUpdate() will
> barf up an SQLException, which will cause PGXAResource to throw an
> XAException yada yada yada which will cause the TM to rollback the
> transaction. So at least they won't be in Dangling Transaction Hell.

Well, that's a given; I'd be complaining much more loudly if it silently
ate errors!

> Anyway, I'm counting on Postgres users knowing what they're doing, esp.
> with something as non-trivial as XA support.

You can't really assume that users of XA are familiar with the details
of our particular XA implemenation, like "a syntax error at this point
means your backend is too old".

Back to my original point: It Needs A Better Error Message. How you do
this I don't really care, checking the server version just seemed like
the most reliable way to distinguish "it doesn't support 2PC" from "some
random connection error".

>> Isn't that covered by tracking the state of the one transaction that's
>> currently in progress on the connection? i.e. if you get asked to
>> rollback() while it's active, you do a rollback(); otherwise you do a
>> ROLLBACK PREPARED.
>
> I think you're right. I also think this is a matter of style/personal
> preference. I like to give classes some of the responsibility for their
> correct usage. It makes it easier to diagnose problems when a class
> instance is used incorrectly.

My point was you can still do 90% of this without the extra complexity,
and the other 10% will get handled by the server (if, for example, a
broken TM asks to commit a transaction that was never prepared)

Complexity is bad for maintenance. I'm probably going to end up at least
helping with maintenance of this code, which is why I'm complaining up
front.

-O

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Oliver Jowett 2005-07-27 05:33:13 Re: jdbc xa patches
Previous Message Michael Allman 2005-07-27 05:13:39 Re: jdbc xa patches