Re: PostgreSQL XAResource & GlassFish 3.1.2.2

On 12.02.2013 05:36, Bryan Varner wrote:
> * Race conditions as multiple threads are participating in the same transaction, invoking XAResource methods. Status checks in PGXAConnection.java are throwing exceptions (if state == ACTIVE) throw) by the time in invokes the throw, the state is != ACTIVE) Before you start telling me I shouldn't be using threads in a JEE environment let me remind you that EJBs by default are served out of thread pools, and allow for concurrent threads to participate within a single TX scope. This is outlined as part of the transaction context in the JTS spec (section 2.2 and 2.3) and synchronized thread-safe access to XAResources is described (without being explicitly called out) by the JTA 1.0.1 spec.

We could fairly easily just add "synchronized" to all the public
methods. I wonder how sane it is for Glassfish to be doing that in the
first place, though. AFAICS, in any combination of two XAResource
methods, called concurrently, one of the threads will get an error
anyway. For example, if two threads try to call start() at the same
time, one of them has to fail because an XAResource can only be
associated with a one transaction at a time.

> * It appears that a second thread attempting to join an existing XAResource's scope with start(XID, TMJOIN) is going to be refused, even if it's attempting to participate in the same XID. The exception thrown is one complaining about interleaving, even though it's the -same- XID, not a sub-set of work in another TX.

Hmm, so the application server is trying to do something like this:

xares.start(1234, 0);
xares.start(1234, TMJOIN);

We could easily allow that in the driver (ie. do nothing), but that
doesn't seem like valid sequence of calls to begin with. You must
disassociate the XAResource from the current transaction with end(),
before re-associating it with start().

If you have a simple stand-alone test application that reproduces the
problems, I could take a closer look.

- Heikki