Stateful Session Bean Lifecycle
Now that you have learned how to specify, implement, and deploy stateless Session beans, it is time to look at stateful Session beans. As you shall see, there are many similarities (especially with regard to the deployment), but the lifecycle is different and warrants close attention.
The client's view of the lifecycle of a stateful Session bean is identical to that of a stateless Session bean and, in truth, more closely matches the actual lifecycle as managed by the container. Figure 5.13 shows this lifecycle.
Figure 5.13. The client's view of the lifecycle of stateful beans is identical to that of stateless Session beans.
From the client's perspective, the bean is simply instantiated when the client calls create() on the bean's home interface, and it's removed when the bean calls remove() on the bean itself.
The bean's viewpoint of its lifecycle is as shown in Figure 5.14.
Figure 5.14. A stateful Session bean's view of its lifecycle includes passivation and timeouts.
The principle difference between stateful and stateless Session beans is the duration of the time that the bean is bound to the client. With a stateless Session bean, the duration was only as long as the time needed to execute the business method. With a stateful Session bean, however, the bean stays bound until the client releases it. In this way, there is a quite close correspondence between the client's and the bean's perspectives.
When the client calls create() on the home interface, a Session bean instance is obtained. Most EJB containers maintain a pool of unbound Session bean instances, so any unused instance will be chosen. This is then bound to the client. The client can call business methods on the bean, and because the bean will remain bound, these can legitimately save to instance variables the state pertaining to the client. When the client is done with the bean, it calls remove() which releases the bean back to the pool of unbound instances.
The EJB specification uses the analogy of a shopping cart, and it is easy to see that this is a natural fit. In such a case, the client would obtain a shopping cart bean using create(), call methods such as addItem(), removeItem(), and checkout(), and then release the bean using remove().
If there are many concurrent clients, the amount of memory to manage all of the clients' state can become significant. Moreover, there is nothing to prevent a client from acquiring a bean, and then not using it—an abandoned shopping cart in the aisles, if you like. The EJB specification addresses these issues by defining the notions of passivation and of timeouts. Passivation allows the EJB container to release the memory used by a bean, first writing out its internal state to some secondary storage. This is transparent to the bean's client; when the bean is next used, the EJB container first activates the bean. How the EJB container actually implements passivation is not specified, but the specification does require that the Session bean is serializable, so many implementations will take this route and serialize the bean to a file. If a bean is not used for longer than its timeout, it can be timed out and its memory released.
Note
Perhaps surprisingly, the EJB specification does not define how the timeout for a Session bean reference is specified. Section 7.6.3 of the specification indicates clearly that its definition is specific to the EJB container. Usually, the information will be captured in a vendor deployment tool and stored in an auxiliary deployment descriptor.
Equally, the EJB specification does not indicate how the EJB container should decide when to passivate beans (though it does suggest that a “least recently used” strategy can be employed, see section 7.6).
Figure 5.14 showed the bean's viewpoint of its lifecycle, but the actual lifecycle as managed by the EJB container is likely to be different again. After all, the whole point of passivation is to reduce the number of bean instances; if the bean was merely “put to sleep,” that wouldn't have been accomplished, so Figure 5.15 shows the actual lifecycle used by many EJB container implementations.
Figure 5.15. The actual lifecycle of stateful Session beans as managed by the EJB container is somewhat more complex.
When the EJB container passivates a bean, its state is written out to secondary storage. The bean instance is then destroyed. If a client whose bean instance has been passivated invokes a method, the EJB container first re-instantiates the bean by deserializing it from secondary storage. The business method is then invoked.