On 12.02.2013 18:01, Bryan Varner wrote:
> 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 see. I think there's yet another potential explanation: even if
glassfish is careful to invoke the end() only after start() has fully
finished in the other thread, the java memory model does not guarantee
that the effects of the end() in one thread are visible to the other
thread doing the start(). The update of the PGXAConnection's
state-variable might be sitting in the CPU cache of the CPU running the
first thread, not yet visible to the second thread. However, I'm not
sure if glassfish could guarantee that the start() has really finished
before end() is called, without using some operation that would also
force the CPU cache to be flushed, making the effects visible.
In any case, it seems like we should add "synchronized" to all the
public methods in PGXAConnection. The performance penalty should be
minimal, and it would fix any race conditions of that sort.
Can you test the attached patch?
- Heikki