You would have to replace the org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor with a version that allows the concurrent calls. File an RFE for the allow-concurrent-calls feature.
Thanks for a swift reply.
I took a look at the class you implied and these questions arose...
Is the current interceptor private for a single Statefull SessionBean Instance? As it does not seem to use the ThreadLocal to store EJBContext as in a type of solution that is suitable for SecurityProxy's which are mutual for all Beans of same name.
Can you say if using a thread to wait inside the interceptor until Interceptor's EnterpriseContext ctx releases its lock could be a solid solutions, or are there some restrictions or downfalls on this sord of an approach?
If so should the actual container and not the interceptor do the waiting for a freed SessionBean?
The interceptor is a stateless property of the stateless session bean container. The ejb context is associated with the instance cache and hooked into the call via the invocation which serves as the thread local.
Blocking the call until the context is free would be fine and is the default behavior of entity beans.