3 Replies Latest reply on Nov 28, 2004 2:38 PM by starksm64

    concurrent calls to session bean methods

    henkkacre

      Hi,

      In web-logic there is a allow-concurrent-calls tag that prevents SessionBean error when trying to access the methods concurrently.

      How is the prevention of these concurrent calls done in JBoss or are there any solutions? I have understood that the SessionBeans are not allowed to have synchronized in the methods modifiers, am I right?

      This is crusial to me as my client recieves Notifications of which it decides to do calls to session beans methods and the user can at the same time make GUI actions that lead to method calls as well.

      Thanks in advance,

      Henri

        • 1. Re: concurrent calls to session bean methods
          starksm64

          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.

          • 2. Re: concurrent calls to session bean methods
            henkkacre

            Hi,

            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?

            Thanks,

            Henri

            • 3. Re: concurrent calls to session bean methods
              starksm64

              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.