Ole Husgaard wrote:
> 
> Hi,
> 
> Just my US$0.02:

Worth over twice as much as my NZ$0.02 :-(

> If you need more verbose debug-level logging
> to see what is happening with transactions,
> try changing the constant
>   static private final boolean trace = false;
> near the top of org/jboss/tm/TxCapsule.java.

That is useful. I wish I'd done this while debugging the transaction
support in the JCA implementation. Uncommenting the "//DEBUG" lines in
TxInterceptorBMT.java was also useful for this problem.

> Toby Allsopp wrote:
> > I have a BMT SFSB, call it SFBean, that starts a transaction in method
> > a() and then calls a method on a CMT SLSB, call it SLBean.a().
> > SFBean.a() returns without completing the transaction. The client then
> > calls SLBean.b(), which is marked as Required, and JBoss complains that
> > there is already a transaction active and it can't nest the new one.
> >
> > 1. Client calls SFBean.a()
> > 2. SFBean.a() starts a transaction
> > 3. SFBean.a() calls SLBean.a()
> > 4. SLBean.a() returns
> > 5. SFBean.a() returns
> 
> Here, the BMT interceptor ought to
> disassociate the bean transaction from the
> current thread.
> If this does not happen, and the client is
> in the same VM, I guess that the SLBean.b()
> call will have this transaction still
> associated.

Well, the client is in a different VM, so I'm not sure if the next
request uses the same thread or if the thread association is set from
the instance association. I get confused trying to follow all the
interceptors.

Either way, the BMT interceptor is definitely failing to disassociate
the transaction from the thread after the method has returned. My
understanding of what the BMT interceptor should do is this:

1. callerTx = tm.disassociateThread()
2. tm.associateThread(instanceTx)
3. getNext.invoke()
4. newInstanceTx = tm.disassociateThread()
5. tm.associateThread(callerTx)

I'm not sure if the BMT interceptor needs to do anything with
newInstanceTx or if that's associated with the instance somewhere else.

Currently it misses step 4, which wouldn't matter if it didn't skip step
5 when callerTx is null.

I'm itching to clean up TxInterceptorBMT now - it's a horrible mess of
TABs and spaces for indenting that makes it hard to follow, so if it's
agreed that I understand this sufficiently I'll make the change (and add
a test for it).

Toby.


--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
List Help?:          [EMAIL PROTECTED]

Reply via email to