Re: jdbc xa support - Mailing list pgsql-jdbc

On Fri, 22 Jul 2005, Oliver Jowett wrote:

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

The C version takes an argument specifying the maximum number of xids to
recover.  The Java version does not.  Without this information, the Java
version not only looks silly but doesn't make a lot of sense either.  For
example, how many recovered xids should we return on the first call to
recover()?

Anyway, do you think my implementation of the recover() method violates
the JTA spec?

Michael