Re: PostgreSQL XAResource & GlassFish 3.1.2.2
От | Florent Guillaume |
---|---|
Тема | Re: PostgreSQL XAResource & GlassFish 3.1.2.2 |
Дата | |
Msg-id | CAF-4BpNWb_XForP6f7dWxncfwm7bbdyL6EWPHHOp3W7C2NfWDA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL XAResource & GlassFish 3.1.2.2 (Bryan Varner <bvarner@polarislabs.com>) |
Ответы |
Re: PostgreSQL XAResource & GlassFish 3.1.2.2
|
Список | pgsql-jdbc |
Maybe in PGXAConnection the field state (and maybe others) should be volatile? Florent On Tue, Feb 12, 2013 at 5:01 PM, Bryan Varner <bvarner@polarislabs.com> 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. > > > I think there's some confusion between a thread and a logical transaction > (represented by a physical connection to the db), with an XID managed by a > Transaction Manager. > > In an JEE container, it's expected that multiple threads will do work on > behalf on a single XAResource, managed by the transaction manager. A single > XID (XAResource) will have multiple threads doing work on their behalf. This > does not necessitate interleaving, but it does mean that multiple threads > can be invoking start() and end() on an XAResource. > > >>> * 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(). > > > You're correct, after doing a bunch more reading, the code path above is > invalid. > > What should be valid (and is not considered interleaving), is: > > Thread A Thread B > -------- --------- > xares.start(1234, TMNOFLAGS); > doStuff(); > xares.end(1234); > xares.start(1234, TMJOIN); > doStuff(); > xares.end(1234); > xares.start(1234, TMJOIN); > doStuff(); > xares.end(1234); > > So long as the TM is serializing execution of A and B and not allowing > branch interleaving. > > In this case, the XAResource is preforming work on behalf of more than one > thread, but in the same XID context. The problem I think I'm seeing at this > point (still trying to coordinate with the glassfish devs) is that the > XAResource isn't fully completing execution of end() prior to the other > thread invoking start(), even though the method invocation appears to be > happening 'in order'. This would manifest as a classic race condition, and > would not constitute transaction interleaving, since the XID in use is the > same TX branch. > > I'm working on a test case as part of the XAResource test suite in the > driver codebase, as I'm doing this, I'm trying to nail down how glassfish is > synchronizing access to XAResources, so this is taking me some time. > > What I can tell you, is that I'm seeing exception cases in my prod > environment where the currentXid.equals(xid), but where the state field in > XAConnection hasn't been updated by a concurrent calls to start()/end() in > time to pass the interleaving pre-condition checks. My current hypothesis is > that GF isn't trying to do interleaving, but the internal state field isn't > being updated 'fast enough' (thread-safely) to avoid race conditions in > non-interleaved, but multi-threaded environments. > > Regards, > -Bryan > > > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
В списке pgsql-jdbc по дате отправления: