Re: jdbc xa support - Mailing list pgsql-jdbc

Heikki,

Thanks for your feedback.  I am working on improvements and documentation.
The rest of my response is below.

On Thu, 21 Jul 2005, Heikki Linnakangas wrote:

> Thanks.
>
> So far so good. You still have all the same tough issues ahead as I do,
> though.
>
> I realize it's work in progress, but here's some comments in no particular
> order:
>
> 1. To answer the question in the source code: PostgreSQL doesn't support
> transaction timeouts

I figured.

> 2. Using prepared statements like "PREPARE TRANSACTION ?" won't work. You can
> only use prepared statements for normal SELECT/UPDATE/DELETE commands.

Doesn't the driver support client side prepared statements?

> 3. How are you planning to handle transaction interleaving discussed in the
> thread Dave mentioned?

I'm not.  PostgreSQL does not support this behavior, and I see no need to
pretend it does.  I think the appropriate thing to do is throw an
exception when the second start is called.

I have serious doubts that any SQL database in the world supports this
behavior correctly.  If you know of one that does, I'd like to see its
magic.

> 4. recover is broken because it ignores the flags argument. That's going to
> cause an endless loop in the transaction manager when it tries to recover.
> See this discussion:
> http://forum.java.sun.com/thread.jspa?threadID=475468&messageID=2232566

That is problematic.  The API for recovery is stateful, and, IMHO, poorly
designed.  If you look at the original DTP XA spec you'll see it makes
much more sense.

I don't know what to do about this yet.

> 5. commit and rollback check that the transaction is found in
> XID_TO_TRANSACTION_STATE_MAP. However, after a crash/recover cycle, the map
> will be empty.

I think I have a good solution to this.  I'll post it with my next
patchset, coming soon.  I'll elaborate then.

> 6. isSameRM considers two connections to the same database as different RMs.
> I'm not sure what the implications of this are, but I feel that's not right.
> I have the same issue in my implementation as well...

They're different RM's because you can't join a transaction across two
physical JDBC Connections.  Each XAResource instance is associated with
exactly one physical connection instance.

In light of the implementation, I could probably just define isSameRM() as
return this == otherXAResource . . .

> Also take a look at a list of comments on my code by Mike Bonnet. Some of
> them probably apply to your code as well. Those comments are about the
> version that's on my pg webpage:
>
> http://users.tkk.fi/~hlinnaka/pgsql/

I saw these.  Nothing jumped out at me.  The documentation is inadequate,
and I'll work on that.  The logging may be inadequate.  I don't know about
that.  I've used this kind of XA implementation before and this kind of
logging has been adequate for me to debug problems.

> The XA and JTA specifications are quite complicated. I'd like to see a good
> set of test cases that exercise all possible scenarious and also error
> conditions. We're also going to need testers with access to the popular
> application servers so that we know our implementation works with them.
> AFAIK, the only open source application server that does recovery properly is
> the CVS head version of JOnAS.

I have some cactus test cases for an XML database that has an XA driver.
I'm not feeling too motivated to port them to PostgreSQL.

> Also, if we violate some parts of the specs (like the transaction
> interleaving part), it's important to know exactly what the limitations are
> and why. I started to write down the exact preconditions for each method in
> the javadoc comments, and also  separate which preconditions come from the
> specs and which are just implementation-specific limitations.

I think the interleaving business is a non-issue.  I can't think of a real
world case where a transaction manager would do this.  Can you?

Besides, like I said, I doubt any other SQL database supports this.  I
know Berkeley DB does, but Berkeley DB lets you associate any database
call with any transaction, so it's easy.

JTA was written with more than just SQL databases in mind, and I don't
think we need to bend over backwards to implement some corner
functionality for a resource which, by its design, doesn't support it.

Thanks again.  I'll post another revision which fixes recovery and
addresses other issues soon.

Michael

> On Wed, 20 Jul 2005, Michael Allman wrote:
>
>> Here's my first cut:
>>
>> http://www.allman.ms/pgjdbcxa/pgjdbcxa-20050720.jar
>>
>> At this point I know the documentation is sparse.  I'll try to improve that
>> situation soon.  Until then, I wanted to give everyone the opportunity to
>> take a first look at the code and the approach.
>>
>> I also have some questions, some of which are embedded in the .java files
>> as comments.  If anyone has answers, please pass them along.
>>
>> I'll let you chew on this and check back tomorrow.
>>
>> Cheers,
>>
>> Michael
>>
>> On Wed, 20 Jul 2005, Heikki Linnakangas wrote:
>>
>>> I'm working on it. Glad to hear your interested. I don't have much time to
>>> work on it though, so I would be very happy if you took over.
>>>
>>> I'll send you a copy of my workbench off-list so you can take a look. It's
>>> work in progress, but I hope it helps..
>>>
>>> I believe this is the discussion Dave mentioned:
>>>
>>> http://archives.postgresql.org/pgsql-jdbc/2005-06/msg00165.php
>>>
>>> - Heikki
>>>
>>> On Tue, 19 Jul 2005, Dave Cramer wrote:
>>>
>>>> Not sure, but look at the archives, there was some discussion about
>>>> various mechanism.
>>>>
>>>> Dave
>>>> On 19-Jul-05, at 7:34 PM, Michael Allman wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm implementing XA support in the postgres JDBC driver to complement
>>>>> the backend two phase commit support in CVS.  Is anyone else working on
>>>>> this?
>>>>>
>>>>> Michael
>>>
>>> ---------------------------(end of broadcast)---------------------------
>>> TIP 4: Have you searched our list archives?
>>>
>>>              http://archives.postgresql.org
>>>
>>
>
> - Heikki
>