Re: jdbc xa support - Mailing list pgsql-jdbc

From Heikki Linnakangas
Subject Re: jdbc xa support
Date
Msg-id Pine.OSF.4.61.0507212140250.34894@kosh.hut.fi
Whole thread Raw
In response to Re: jdbc xa support  (Michael Allman <msa@allman.ms>)
Responses Re: jdbc xa support
Re: jdbc xa support
List pgsql-jdbc
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

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

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

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

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.

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...

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/

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.

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.

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

pgsql-jdbc by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Timestamp Conversion Woes Redux
Next
From: "Kevin Grittner"
Date:
Subject: Re: Timestamp Conversion Woes Redux