Passivation and Activation

Because resources for the container are finite, it might become necessary for the container to temporarily remove enterprise bean objects to a secondary storage so that the resources the enterprise bean were using can be reclaimed and used for something else. This process of removing EJBs from the container is known as passivation and when the server brings the EJB back into memory from secondary storage, this is known as activation .

Passivation and activation can happen as part of the container's normal resource management policy. The container doesn't have to be out of resources for passivation to occur for a bean. In fact, to prevent ever getting close to being out of resources, the container can initiate this action on one or more idle enterprise beans. When and under what circumstances this will occur is totally up to the container and vendor implementation. However, the container is not permitted to passivate a bean that is within a current transaction or when a bean is servicing a client. If the container were allowed to passivate beans that were in the middle of a transaction or in a business method for a client, this would most likely cause the database or application to be put into an unpredictable state, so this is prevented by the specification.

Although vendors have flexibility on how they persist the state of an EJB object during passivation, the passivation mechanism by an EJB server must follow the rules of Java serialization. This is in case serialization is used to passivate the objects. This will help ensure portability across EJB vendors . The rules also include ones that normally apply to transient fields on a serializable object. Bean providers should assume that transient fields would not be saved during passivation and activation.

All entity and session beans are required to implement the ejbPassivate and ejbActivate methods. These methods are declared in the javax.ejb.EntityBean and javax.ejb.SessionBean interfaces. The method ejbPassivate is called right before the container removes the bean instance from memory or returns it back to a pool. You'll see more on what pools are used for in the next section. The method ejbActivate is called after the EJB object is re-created and before any client invocations occur on it.

When the ejbPassivate method is complete, the bean provider must ensure that the bean is ready to be stored by the container. This means that all external resources held by the bean (like JDBC connections or client sockets) must be released and cleaned up.

Note

For references that hold on to JDBC connections and other external resources, you should also set the instance fields storing these references to null .

Also, all instance fields must be ready for serialization. Objects that are held by the bean that is going to be passivated must be one of the following for passivation to work:

• A serializable object

• Null

• A reference to an enterprise bean's component interface

• A reference to an enterprise bean's home interface

• A reference to the SessionContext object

• A reference to the environment-naming context

• A reference to the UserTransaction interface

• A reference to a resource manager connection factory

• An object that is not initially serializable but acquires the ability to be serializable based on the home and component references serialization process

Note

We have not discussed what a SessionContext or UserTransaction is yet, but don't worry if these terms don't make sense. We formally introduce SessionContext in Chapter 9 and UserTransaction in Chapter 12.

Because the ejbPassivate and ejbActive methods reside in interfaces that your bean must implement, these methods must be implemented in every bean. In cases where you're not holding onto resources within your bean instance that must be maintained during passivation and activation, you won't need to do anything during these methods. However, you are still required to have the callback methods in your beans. In the cases where you don't need to do anything, you can just provide empty methods. The class in Listing 3.10 provides empty implementations for the passivation and activation methods.

Listing 3.10 Example Bean Implementing ejbPassivate and ejbActive Methods

 import javax.ejb.CreateException;  import javax.ejb.SessionBean;  import javax.ejb.SessionContext;  import javax.ejb.*;  public class OrderFulfillmentProcessorBean implements SessionBean {   private SessionContext ctx;    /**     * This method is required by the EJB Specification,     * but is not used by this example.     *     */    public void ejbActivate() {   }    /**     * This method is required by the EJB Specification,     * but is not used by this example.     *     */    public void ejbRemove() {   }    /**     * This method is required by the EJB Specification,     * but is not used by this example.     *     */    public void ejbPassivate() {   }    /**     * Sets the session context.     *     * @param ctx  SessionContext Context for session     */    public void setSessionContext(SessionContext ctx) {     this.ctx = ctx;    }    /**     * Complete the customer's order and prepare for shipping     *     * @param orderId      Unqiue Order identified     * @return             void     *     */    public  void completeOrder (String orderId) {     // Do something in this method to complete the order    }  } 

Note

You should also be aware that there are other callback methods required by the container in your enterprise beans. A session bean must also implement the ejbRemove and setSessionContext methods, for example. You can provide an empty implementation for the ejbRemove method if you don't need to do anything special, but you should set the SessionContext reference passed to your bean to an instance variable in your bean. The SessionContext provides access to the container's environment.