This chapter is from the book
This chapter is from the book
This chapter is from the book
Life Cycle of Session Beans
Stateful and stateless session beans have different life cycles. The stages from the time they are instantiated, ready to be used, and then destroyed vary from one type to another. We will examine the life cycle of each stateless and stateful session bean in the following sections.
Stateless Session Bean Life Cycle
Figure 3.1 shows the life cycle of a stateless session bean instance. If you are not familiar with state diagrams, we recommend that you read Appendix D, "Introduction to UML Notation," before you read this section.
){kind=link}
Figure 3.1 Stateless session bean life cycle.
The following steps describe the life cycle of a stateless session bean instance:
The bean instance's life cycle starts when the container decides to instantiate a bean instance. This decision is based on the caching policy and client demand. For example, if more clients want the session bean services, the container instantiates more beans. The container allows you to specify the caching policy in a vendor-specific deployment descriptor.
The container instantiates the bean using the newInstance method and then calls the methods setSessionContext and ejbCreate. The container also sets the transaction context and security attributes (as set in the deployment descriptor). Now the bean is ready to serve any client.
The container calls a business method on the instance, based on the client call. Note that container could use the same instance to serve multiple clients.
The container decides to remove the bean instance. This could be because the container wants to reduce the number of instances in the method-ready pool. This is based on the caching policy and reduced demand.
Container calls the ejbRemove() method of the bean instance.
Life Cycle of a Stateful Session Bean
Figure 3.2 shows the life cycle of a stateful session bean instance.
){kind=link}
Figure 3.2 Stateful session bean life cycle.
The following steps describe the lifecycle of a stateful session bean instance:
The bean instance's life cycle starts when a client invokes create<method>(...) on the session bean's home interface. The container instantiates a new session bean using newInstance() and then calls the setSessionContext method, followed by ejbCreate<method>(...).
The instance is now ready to serve the client's business methods.
The container decides to evict your instance from memory. This decision is based on the container's caching policy and reduced demand. The container invokes the ejbPassivate() method on the instance and swaps it out to secondary storage.
If a client invokes a session object whose session bean instance has been passivated, the container will activate the instance. To activate the session bean instance, the container restores the instance's state from secondary storage and issues ejbActivate() method on it. The session bean instance is again ready for client methods.
When the client calls remove on the home or component interface to remove the session object, the container issues ejbRemove() on the bean instance. This ends the lives of the session bean instance and the associated session object. Note that a container can also invoke the ejbRemove() method on the instance without a client call to remove the session object after the lifetime of the EJB object has expired.
NOTE
You cannot rely on the container calling the ejbRemove() method. The container might not call ejbRemove() in the following scenarios: a) A timeout due to client inactivity while the instance is in the passive state; b) A shutdown or crash of the container; c) A system exception thrown from the instance's method. If your instance frees up resources in the ejbRemove() method, those resources are not freed in the preceding scenarios.
You should provide some mechanism to periodically clean up the unreleased resources. For example, if a shopping cart component is implemented as a session bean, and the session bean temporarily stores the shopping cart content in a database, the application should provide a program that runs periodically and removes abandoned shopping carts from the database.