Re: jdbc xa support

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