Re: PostgreSQL XAResource & GlassFish 3.1.2.2 - Mailing list pgsql-jdbc

On 13.02.2013 17:20, Bryan Varner wrote:
> I've been doing a lot (a LOT) of catching up on JTA over the last few
> days, and I have some concerns about some of the sanity checks in the
> driver.

I'm all ears.

>> Another reason is that because the implementation doesn't support
>> transaction interleaving and suspend/resume, it checks that the
>> transaction manager doesn't try to do that. If it does, you get a
>> meaningful error, "Transaction interleaving not implemented". That's a
>> clue to the user to configure the transaction manager to not do that.
>
> Fair enough, if the TM allows for that configuration.

It's not required by the spec, but in practice all the TM's have an
option for that, because many JDBC implementations don't support those
features; the PostgreSQL driver isn't alone with that.

> After synchronizing the methods, the 'failures' we're getting in regards
> to TM invocation of the XAResources seem to all be centered around
> section 3.4.6 part of the JTA spec.
>
> Specifically, we're seeing commit() invoked with xid's that don't match
> the XAResource's currentXid, as well as commit() called on connections
> which have no currentXid. This appears to be behavior that's within spec...

Right, assuming they are 2nd phase commits (onephase parameter ==
false), the TM is free to use any XAResource instance. The PG driver
requires the XAResource to not be associated with a transaction, however.

> I understand that XA isn't easy to do (or else everyone would), but it's
> almost like the PG implementation is missing a layer of indirection
> between the physical connections (pegged to currently serviced xids) and
> the logical connections in use by the client application. I think the
> best way I can describe this is, from what I'm seeing, it's like JTA
> expects the XAResource being returned by an XAConnection isn't pegged to
> (or required to represent) a physical connection, but (potentially)
> operates upon one or more physical connections to service the
> invocations of the TM upon the appropriate physical connection.
>
> Am I completely off the mark here?

I think it's more like the JTA authors expect there to be methods in the
underlying FE/BE protocol to associate/disassociate a transaction from
the physical connection.

The JTA spec is based on the X/Open spec, which was written for a quite
a different world. I think the X/Open spec assumes a single operating
system process running a single thread; being able to suspend/resume a
transaction makes a lot more sense in that context. It didn't translate
well to the Java world.

- Heikki