Re: jdbc xa support - Mailing list pgsql-jdbc

Michael Allman wrote:
> On Fri, 22 Jul 2005, Oliver Jowett wrote:
>
>> Michael Allman wrote:
>>
>>>> 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.
>>
>>
>> Huh? TMSTARTRSCAN etc are in the original DTP XA spec too, assuming you
>> mean this one:
>>
>> X/Open CAE Specification
>> Distributed Transaction Processing: The XA Specification
>> ISBN: 1 872630 24 3
>> X/Open Document Number: XO/CAE/91/300
>
>
> Yes, and if you look at the specification for the xa_recover() function
> 47 you see it's a lot different from its Java counterpart.

Actually, I don't see that at all; the Java API is pretty much a direct
mapping of the C API. Quote from the C API:

===
So that all XIDs may be returned irrespective of the size of the array
xids, one or more xa_recover () calls may be used within a single
recovery scan. The flags parameter to xa_recover () defines when a
recovery scan should start or end, or start and end. The start of a
recovery scan moves a cursor to the start of a list of prepared and
heuristically completed transactions. Throughout the recovery scan the
cursor marks the current position in that list. Each call advances the
cursor past the set of XIDs it returns.
[...]
Upon success, xa_recover () places zero or more XIDs in the space
pointed to by xids. The function returns the number of XIDs it has
placed there. If this value is less than count, there are no more XIDs
to recover and the current scan ends.
[...]
Following are the valid settings of flags:
TMSTARTRSCAN
This flag indicates that xa_recover () should start a recovery scan for
the thread of control and position the cursor to the start of the list.
XIDs are returned from that point. If a recovery scan is already open,
the effect is as if the recovery scan were ended and then restarted.
TMENDRSCAN
This flag indicates that xa_recover () should end the recovery scan
after returning the XIDs. If this flag is used in conjunction with
TMSTARTRSCAN, the single xa_recover () call starts and then ends a scan.
TMNOFLAGS
This flag must be used when no other flags are set in flags. A recovery
scan must already be started. XIDs are returned starting at the current
cursor position.
===

Java API:

===
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
recovery scan. 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 passed the
set of Xids that are returned.
[...]
flag
One of TMSTARTRSCAN, TMENDRSCAN, TMNOFLAGS. TMNOFLAGS must be used
when no other flags are used.
TMSTARTRSCAN - indicates that the recovery
scan 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
Returns: xid[]
The resource manager returns zero or more Xids for the transaction
branches that are currently in a prepared or heuristically completed
state.
====

The only significant difference is that the Java API doesn't talk about
how to signal no-more-XIDs .. I'm guessing this is just an oversight.
The thread referred above to mentions using a null or zero-sized return
from recover() to signal that.

But both the Java and C versions are stateful and essentially
equivalent, so I'm not sure what your complaint is exactly..

-O