Each Statefull session beans is created for one client only. If client is inactive for a while, the bean is removed and ejbRemove() is called. On the other hand, if container expects that it's not too late yet and client may come back, then to conserve resources, conatiner may passivate the bean. If and when client comes back within the same session, the ejbActivate() will be called on the bean. The bean may be removed while the bean is passivated. ejbRemove() will not be called in that situation. If bean is killed while in active state, then only ejbRemove() is called.
The container decides when to passivate a bean. This would be typically determined based on the resource availability. This feature is entirely dependent on the vendor. ( A vendor can decide to passivate after every method call. Another vendor would passivate a bean based on some caching algorithm only when the memory resources are short).
Similarly the EJB spec specifies, that a container must have the capability to remove a stateful bean on its own if it remains idle for certain duration. How it is implemented is entirely container / vendor dependent.
Lets consider weblogic EJB container. It provides two parameters for the deployer to configure: 1) max-beans-in-cache: This is the maximum allowed stateful bean instances in cache 2) idle-timeout-seconds: time upto which a stateful bean can remain idle after which it can be removed from cache.
For example: consider the following configuration: max-beans-in-cache: 2 idle-timeout-seconds: 600
Scenario1: There are two beans EJB1 and EJB2. EJB1 is in the middle of executing a method. EJB2 has been idle for 20 seconds. When a request comes to create a new stateful bean, EJB2 would be passivated , as the max-beans-in-cache has reached and EJB2 is idle.
Scenario2: There are two beans EJB1 and EJB2. EJB1 is in the middle of executing a method. EJB2 has been idle for 601 seconds. When a request comes to create a new stateful bean, EJB2 would be removed , as the max-beans-in-cache has reached and EJB2 is idle for more than the allowed duration.
The important point to remember is that, conatiner has the ability to passivate or remove a stateful bean. The bean provider should consider this when developing an application using stateful beans. How this would be handled is entirely dependent on the container.
Refer to the stateful bean lifecycle in EJB specs: section 7.6, page 77.
Regarding your question
Im still not clear how the container decides when to call remove and when to call passivate. Is it that passivate timeout < remove timeout?
IF a container provider does passivation and removal based on only two parameters (say) passivate-timeout and remove-timeout, then inorder to use the resources effectively, passivate-timeout must be less than remove-timeout. If remove-timeout > passive-timeout, then passivation will never take place. The bean will be removed directly after the specified timeout period. [ January 01, 2006: Message edited by: Sankar Subbiramaniam ]
pie. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop