2 Replies Latest reply on Oct 22, 2009 10:33 AM by surfratwalt

    Stateless Session Bean is holding conversational state acros

      Hi,

      I have recently taken over an EJB3 project running on JBoss 4.0.5 in prod, (4.2.3 in dev) and upon inspecting the legacy code have noticed that there are many situations where a Stateless Session Bean appears to hold state accross method calls (I.e. conversational state). At first I couldn't believe the application was working and producing results in a consistent manner, as the EJB spec clearly states that SLSBs hold no conversational state between client calls, but alas, I was astounded to find out that it in fact does work. And it is relatively consistent (to the best of my knowledge).

      An very typical example of the interactions with a SLSB by a client in the code base is identified in the following example classes.

      
      @local(X.class)
      @Stateless
      private class MyStatelessBean implements X{
      
       private Object localProp1, localProp2;
      
       public void setLocalProp1(Object val) {...}
      
       public void setLocalProp2(Object val) {...}
      
       public void doSomethingWithProps() {}
      }
      
      private class MyPojoClass {
      
       private void run(Object arg1) {
      
       MyStatelessBean mySLSB = ... // lookup JNDI
       mySLSB.setLocalProp1(arg1);
       mySLSB.setLocalProp2(getArg2()); // maybe different session bean instance from pool ??
      
       mySLSB.doSomethingWithProps(); // <== this call requires same bean instance from pool ??
       }
      
       private Object getArg2() {
       // do some work to get arg 2
       }
      }
      
      


      In this example a client sets two properties on the bean and then tells it to do something with the values. If the values were not set, or exactly what was set, then our application would fall over. But it doesn't. I have tried to write tests to break it under load, even with multi-threaded calls, however have failed to do so.

      Now I'm wondering if anyone can explain this for me as I have told my Boss that we need to change this architecture (even though it is working).

      I can only think that as the calls mostly come from a single thread and more than likely execute in quick succession, it is simply JBoss's implementation of the stateless session pool which is actually supplying the same session bean instance for each call (perhaps for performance). I suspect other J2EE application servers might not be so consistent.

      Can anyone enlighten me or confirm my thoughts on this please?

      If you are wondering the config for the container slsbs is:

      <container-configuration>
       <container-name>Standard Stateless SessionBean</container-name>
       <call-logging>false</call-logging>
       <invoker-proxy-binding-name>stateless-rmi-invoker</invoker-proxy-binding-name>
       <container-interceptors>
       <interceptor>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor</interceptor>
       <interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor>
       <interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor>
       <!-- CMT -->
       <interceptor transaction="Container">org.jboss.ejb.plugins.TxInterceptorCMT</interceptor>
       <interceptor transaction="Container">org.jboss.ejb.plugins.CallValidationInterceptor</interceptor>
       <interceptor transaction="Container">org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor</interceptor>
       <!-- BMT -->
       <interceptor transaction="Bean">org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor</interceptor>
       <interceptor transaction="Bean">org.jboss.ejb.plugins.TxInterceptorBMT</interceptor>
       <interceptor transaction="Bean">org.jboss.ejb.plugins.CallValidationInterceptor</interceptor>
       <interceptor>org.jboss.resource.connectionmanager.CachedConnectionInterceptor</interceptor>
       </container-interceptors>
       <instance-pool>org.jboss.ejb.plugins.StatelessSessionInstancePool</instance-pool>
       <instance-cache></instance-cache>
       <persistence-manager></persistence-manager>
       <container-pool-conf>
       <MaximumSize>100</MaximumSize>
       </container-pool-conf>
       </container-configuration>
      


      Thanks.