|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Ole Husgaard
|Sent: Thursday, October 19, 2000 1:56 PM
|To: jBoss Developer
|Subject: [jBoss-Dev] Transaction handing in stateless containerinvoker
|
|
|Hi,
|
|I am currently trying to track down the problem
|of a NPE thrown from TransactionImpl.getStatus()
|called from the BMTInterceptor on return from a
|invokcation on a stateless BMT bean.
|This only happens if the BMT bean was called from
|another bean in a transaction context.
|
|The problem was that the TransactionImpl that came
|with the invocation of the BMT bean was never
|imported into the transaction manager (all instances
|of TransactionImpl should be imported after
|travelling over RMI, and for CMT this is done
|implicitly in TxMamager.associateThread())
yes this is the right place to put it, and doing it implicitely is also
right.
|, but this
|transaction was being used to check that it was
|terminated on return from the stateless BMT bean.
|
|But of course we should not have to import the
|client transaction coming in the MI, as that should
|never be used in a BMT bean.
that is correct, in fact the spec says to suspend association in case of a
BMT bean, the MethodInvocation carries the old transaction from the previous
thread... which is normal but should not be wired.
|After a lot of head scratching while wondering how
|come a transaction that should not be used is
|suddenly the current transaction of the enterprise
|context on return from BMT.invoke() but not on entry,
|I finally found the offending code:
|In StatelessSessionContainer.ContainerInterceptor.invoke()
|I found this piece of code:
| // wire the transaction on the context, this is
| // how the instance remember the tx
| if (mi.getEnterpriseContext().getTransaction() == null)
|
|mi.getEnterpriseContext().setTransaction(mi.getTransaction());
|
|Problem is that mi.getTransaction() returns the
|transaction (that was never imported and should not
|be used) of the caller.
;-)
this is normal and he is not "responsible", this piece of code just does
what he is told which is to tell the context what is on the
MethodInvocation.
The code that is bad is the TxInterceptorBMT that does not clean the
MethodInvocation Tx stuff when it should (since we "suspend" any
association)... It suffices to get the tx from teh bean and set it on MI...
I will do that right now.
|
|I wonder why this code is placed here.
|Doesn't it belong in the transaction interceptors?
No, CMT for example doesn't have the context and so no wiring can happen.
BMT does but then it is not symmetrical and we must code all over the place.
Again I think the right fix is another piece of code, I will commit right
now, stay tuned
marc
|
|Please advice.
|
|
|Best Regards,
|
|Ole Husgaard.
|
|
