Hi,
Aaron Mulder wrote:
> So, who is osh?
That's me.
> Osh, what's the problem with invalid XA resource
> state?
When calling out from the TxCapsule to do a XA resource
start() or end(), I temporarily release the lock on the
TxCapsule so that if the XA resource tries to do
something with the transaction there will be no
deadlock.
To make sure I give the XA resource the right flags,
I maintain some state information about each XA
resource in TxCapsule.resourceState[].
But currently this state may not be up-to-date when
the TxCapsule lock is released for calling out, and
that may give problems if another call with the same
XA resource comes in while TxCapsule calls out.
For example: If the TxCapsule holds an XA resource
reference xaRes, and the transaction should be rolled
back due to a timeout. xaRes.end() is called with the
TxCapsule lock temporarily released to avoid deadlock.
But the state information I hold to know if I already
have done xaRes.end() isn't updated until xaRes.end()
returns. Now imagine that transaction commit happens
while doing the xaRes.end() call. Then a second call
to xaRes.end() could happen, and a XAException be
(correctly) thrown from the XA resource.
I suspect that updating the state _before_ releasing
the lock may give other problems.
The real problem, I guess, is that JTA does not
explicitly forbid an XA resource calling the
transaction during the start() and end() calls,
so although Minerva does not do it, other XA
resource implementations might.
The right thing would probably be to add a new
TxCapsule internal resource state RS_TRANSIENT that
is used during the callout to start() and end().
Best Regards,
Ole Husgaard.
