Re: jdbc xa support

On Fri, 22 Jul 2005, Oliver Jowett wrote:

> Michael Allman wrote:
>
>> The C version takes an argument specifying the maximum number of xids to
>> recover. The Java version does not.
>
> That's at least partly because the C version makes the caller allocate the
> array.

In this situation it is understandable why the C method is stateful and
how it is supposed to work. The caller tells the resource manager how
many xids it can handle at once by passing a length argument. It also
passes an XID* which it malloc()'s to hold

length * (3 * sizeof(long) + XIDDATASIZE * sizeof(char))

bytes, or something like that.

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.

This is why I say the Java version doesn't make sense.

>> Without this information, the Java version not only looks silly but
>> doesn't make a lot of sense either.
>
> It seems ok to me -- it puts the burden for selecting a suitable batch size
> on the resource rather than the TM, but that's six of one, half a dozen of
> the other. That also means the RM can generate the array at whatever size is
> convenient, rather than having to internally buffer if it retrieves xids in
> some large block size than the TM selects.
>
> It certainly doesn't make it more or less stateful, so I still don't
> understand your original objection.
>
>> For example, how many recovered xids should we return on the first call to
>> recover()?
>
> 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.

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

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

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.

Michael