[jboss-dev-forums] [Design of EJB 3.0] - Re: IsLocalInterceptor not detecting local container

[bstansberry@jboss.com]

I (mostly) understand what's going on here, but need input from the rest of the EJB3 team on how to fix it and resolve EJBTHREE-881.  I'll post separately later about the bit I don't understand.

Basic problem is very simple:

1) A invocation is made on a parent bean with REQUIRED tx semantics.  Parent delegates to an @Remote nested child; tx is associated with the thread.

2) IsLocalInterceptor will only attempt to directly optimize the call to the local bean if the interceptor instance itself was created in the local VM. So, if an SFSB fails over, the interceptor contained in any nested bean proxy will not have been created in the failover VM and IsLocalInterceptor will not optimize the call.

3) Since the call isn't optimized locally, ClientTxPropagationInterceptor adds transaction metadata to the invocation context.

4) org.jboss.remoting.Client detects that the bean *is* available locally, and executes it locally.

5) TxPropagationInterceptor throws an exception when it finds a tx bound to the thread and tx metadata associated with the invocation that it thinks it should import.


A couple possible solutions come to mind, but I don't know enough to recommend one and certainly won't implement one without someone's OK:

Option A) Make IsLocalInterceptor work more like the EJB3 InvokerInterceptor.
InvokerInterceptor performs the following check when deciding whether to optimize a call locally:

i) check if the interceptor was created in the VM (same as the IsLocalInterceptor).
ii) if not, check if the invocation is for a clustered bean.
iii) if i == true || ii == true, check if the target bean exists locally.

IsLocalInterceptor could be made to work the same way. Odd bit is checking if the invocation is for a clustered bean.  That could be done by checking the invocation metadata for any of the cluster-related bindings.


Option B) Does TxPropagationInterceptor need to fail if there is already a tx associated with the thread?  Could it just accept the existing tx and not bother importing the tx specified in the metadata? Is there any scenario other than this one where a tx would be associated with the thread?

Me thinks Option B is not good, but if there is a reason Option A is no good, it may be needed.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4026031#4026031

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4026031