Skip site navigation (1) Skip section navigation (2)

Re: jdbc xa support

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Michael Allman <msa(at)allman(dot)ms>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: jdbc xa support
Date: 2005-07-21 19:14:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc

So far so good. You still have all the same tough issues ahead as I do, 

I realize it's work in progress, but here's some comments in no particular 

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:

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:

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 

On Wed, 20 Jul 2005, Michael Allman wrote:

> Here's my first cut:
> 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:
>> - 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?

- Heikki

In response to


pgsql-jdbc by date

Next:From: Dave CramerDate: 2005-07-21 20:52:16
Subject: Re: Timestamp Conversion Woes Redux
Previous:From: Kevin GrittnerDate: 2005-07-21 18:04:30
Subject: Re: Timestamp Conversion Woes Redux

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group