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

Re: jdbc xa support

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 support
Date: 2005-07-22 05:56:30
Message-ID: 42E08A8E.5020807@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Michael Allman wrote:

> Without a length argument allowing the TM to tell the RM how many xids 
> it can take, it doesn't make sense to return "some" xids at a time.  
> Because how many "some" is is determined by the RM, not the TM, and that 
> defeats the purpose of the C version's approach.

Well, personal preference perhaps, it seems fine to me to allow the RM 
to break up the list into more manageable parts if it wants to. For 
example, consider a Java RM that is implemented by JNI calls to a C 
implementation of the XA interface.

>> For our JDBC implementation? Set a fetchsize on your query to 
>> something reasonable -- perhaps 500? -- and return up to that many 
>> Xids per call until you hit the end of the resultset, then return 
>> empty arrays thereafter until a new scan starts.
> 
> Why 500?  It's simpler to return all of them.

Sure, it doesn't really matter either way, it's just an implementation 
decision. My only concern was if you're pulling in a million Xids at 
once then you are going to bloat out the heap more than you need to -- 
but that's unlikely to happen in any real system anyway.

>>> Anyway, do you think my implementation of the recover() method 
>>> violates the JTA spec?
>>
>>
>> The code in pgjdbcxa-20050721.jar appears to violate the spec, as you 
>> completely ignore the flags argument. You need to track the recovery 
>> scan state even if you decide to return all Xids in one array, because 
>> subsequent calls shouldn't return those Xids again until a new scan is 
>> started, per the API docs.
> 
> 
> I do track the recovery scan state.  Each call puts the scan cursor at 
> the end of the list.

Uh, are we looking at the same code here? I don't see anything in the 
code from pgjdbcxa-20050721.jar that records whether we are at the end 
of the list or not between calls to recover(), and I don't see anything 
that looks for TMSTARTRSCAN to reset that state. If I've missed it, can 
you point it out to me?

> I still don't see a violation of the API.

The API says that if a TM does this:

   Xid[] xids_1 = resource.recover(TMSTARTRSCAN);
   Xid[] xids_2 = resource.recover(TMNOFLAGS);
   Xid[] xids_3 = resource.recover(TMNOFLAGS);

then xids_1, xids_2, and xids_3 reflect consecutive (and possibly empty 
if you hit the end) parts of the recovery list. It seems your code does 
not respect this -- it will return the full list of Xids repeatedly in 
each of xids_1, xids_2 and xids_3.

Given that the way that the TM decides that the recovery scan is 
complete is by looking for an empty array returned from recover(), your 
code is going to hit exactly the infinite-loop case described in the 
thread that Heikki posted.

> It looks like the JTA API is wrong or there's a typo.  If we follow the 
> spirit of the DTP spec it seems that the TMNOFLAGS flag means "return 
> some xids starting from where we last left off".  I'm still not sure 
> what TMENDRSCAN means.

The JTA specification is fairly clear about their meanings. TMNOFLAGS 
does indeed mean "continue the current scan". TMENDRSCAN means "I'm done 
with this scan", and allows RMs to free resources they have allocated 
for the scan.

===
The flag parameter indicates where the recover scan should start or end, 
or start and end. This method may be invoked one or more times during a 
recoveryscan. The resource manager maintains a cursor which marks the 
current position of the prepared or heuristically completed transaction 
list. Each invocation of the recover method moves the cursor past the 
set of Xids that are returned.

[...]

TMSTARTRSCAN - indicates that the recoveryscan should be started at the 
beginning of the prepared or heuristically completed transaction list.

TMENDRSCAN - indicates that the recovery scan should be ended after the 
method returns the Xid list. If this flag is used in conjunction with 
the TMSTARTRSCAN, this method invocation starts and ends the recovery scan.

TMNOFLAGS - this flag must be used when no other flags are specified. 
This  flag may be used only if the recovery scan has already been 
started. The list of Xids are returned
===

-O

In response to

Responses

pgsql-jdbc by date

Next:From: Michael AllmanDate: 2005-07-22 06:25:47
Subject: Re: jdbc xa support
Previous:From: Michael AllmanDate: 2005-07-22 05:28:08
Subject: Re: jdbc xa support

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