Re: jdbc xa patches

Michael Allman wrote:
> On Wed, 27 Jul 2005, Oliver Jowett wrote:
>
>> We now use 4-space indents, not tabs.
>
> I'm away from my normal dev machine and am flailing away with unfamiliar
> tools.  Do you have a utility that will indent as desired?

perl? :-)

>> Shouldn't the XAResource check the server version on construction or on
>> start()/recover() to make sure that it's actually going to be able to
>> use PREPARE TRANSACTION later? Or is erroring out with a syntax error at
>> the point of prepare() sufficient? (I'd like to see a better error
>> message there at least)
>
> If we call statement.executeUpdate("SOME QUERY POSTGRESQL DOESN'T
> UNDERSTAND") will it throw an instance of SQLException?

Yes, per JDBC spec. Still, it is generally tricky to distinguish a
particular error class from more general errors (SQLSTATE only gets you
so far).

>> Having ResourceAssociationState as a full-blown class seems like
>> overkill since you only have one instance anyway.
>
> Maybe.  Java 1.4 doesn't have enums.  What do you suggest as an
> alternative?

Just a bare int?

>> Is XID_TO_TRANSACTION_STATE_MAP actually necessary? It seems like it's
>> only there for detecting XA protocol errors (which would otherwise show
>> up as errors from the backend, e.g. trying to commit a nonexistant
>> transaction), and for tracking the state of the transaction that is
>> currently suspended or currently associated (of which there can only be
>> one in the current implementation)
>
> In the implementation of rollback() it is used to determine whether to
> call physicalConnection.rollback() or issue a "ROLLBACK PREPARED" query.

Isn't that covered by tracking the state of the one transaction that's
currently in progress on the connection? i.e. if you get asked to
rollback() while it's active, you do a rollback(); otherwise you do a
ROLLBACK PREPARED.

>> I'm not sure it's necessary for recover() to avoid returning
>> non-JDBC-originated transactions; from memory the TM is already required
>> to handle recovered Xids that were not generated by it. (need to check
>> the XA spec here)
>
> Quite the opposite.  The TM is required to ignore xids that were not
> generated by it.

Sorry, that's what I meant by "handle" as in "not complain about" aka
"ignore" :)

> Besides, if someone prepares a transaction with id "whatever", we aren't
> going to be able to decode that to an xid.

I guess that's a good reason.

-O