4 Replies Latest reply on May 18, 2009 2:55 AM by xmedeko

    Stateful bean keep-alive

    xmedeko

      Hi,

      is there any mechanism, how to keep-alive the stateful session bean when accessing it from the Java Swing client? Or do I have to code my own solution?

      Thanks
      Andy

        • 1. Re: Stateful bean keep-alive
          peterj

          Stateful session beans are kept alive until the client closes the session. However, the app server will passivate them to disk if there are too many or they have not been used for a while. You can change the bean idle time, and adjust the cache size, to prevent (or delay) the passivation.

          I would tell you which settings govern this but you did not say what version of JBoss AS you are using.

          • 2. Re: Stateful bean keep-alive
            xmedeko

            Hi Peter,

            I have JB 5.0.1GA. My SFSB is declared with

            @CacheConfig(maxSize = 10000, idleTimeoutSeconds = 60000, removalTimeoutSeconds = 60)


            So, the SFSB is removed after 60 seconds of inactivity (for testing). I got the stub (proxy) for this SFSB in a plain old (standalone) Java application (POJA) via JNDI lookup.

            When there's more then 60 sec. delay between calls to this bean from the application, then the bean is removed. What's the problem: I want the bean to be removed soon, when the application crashes (i.e. when no addShutdownHook was called), but I do not want to remove it, when the user keep the application open and makes no action. E.g. user goes to lunch or takes a nap.

            I was thinking about making a thread in the client application, which will contact the bean in the specified interval (keep-alive calls). But then I have to make sure all calls to the bean are synchronised as well.

            So I was thinking, that there must be more people having similar problem. So I am interested, if there's some existing solution in JBoss for this if I have to code it by myself.

            Thanks
            Andy

            • 3. Re: Stateful bean keep-alive
              peterj

              Don't set removalTimeoutSeconds, use idleTimeoutSeconds instead. See http://www.jboss.org/community/wiki/HowdothetimeoutsworkwithEJB3StatefulBeans This way unused beans are passivated and thus don't remain in memory. You can also set removalTimeoutSeconds to a large value, such as 8 hours. That way if the client really went away, the bean will be removed from the passivation storage are after a while.

              Creating a new client thread might work, but you have to be careful. First, the thread must not lookup the EJB itself - you will end up with a new EJB, not with the one that you want to keep alive. Therefore, you must pass the bean's proxy to the thread. Second, I recommend creating a separate method on the EJB that does nothing - the primary purpose of this method is for the extra thread to occasionally call it. This should guarantee that the state of the bean does not change inadvertently.

              • 4. Re: Stateful bean keep-alive
                xmedeko

                Hello Peter,

                thanks for your reply.

                "PeterJ" wrote:
                Don't set removalTimeoutSeconds, use idleTimeoutSeconds instead. ...


                unfortunately, our session bean cannot be serialized from various reasons. I am moving an existing, a little bit larger, application into JBoss. It would be not easy to make it serializable. (Maybe in the future I will have to do it anyway.)

                "PeterJ" wrote:
                Creating a new client thread might work, but you have to be careful. First, the thread must not lookup the EJB itself - you will end up with a new EJB, not with the one that you want to keep alive. Therefore, you must pass the bean's proxy to the thread. Second, I recommend creating a separate method on the EJB that does nothing - the primary purpose of this method is for the extra thread to occasionally call it. This should guarantee that the state of the bean does not change inadvertently.


                Yes, that what I have already done :-)