Java Tutorial - Java Scipt :
Containers and EJB Life Cycle
Now that you have a good grasp on the various interfaces that an EJB can be composed of, let’s take a look at the life cycle of an EJB and how the container management fits into that picture. The EJB container provides services for the EJBs housed within it. This is done by wrapping the EJBs and managing access to them. The focus is usually
on the benefits added by the EJB container, but to provide them, the EJB container must manage the life cycle of EJBs. As developers, it is important to understand this life cycle model and what effect it has on the way EJBs are coded. EJBs share many aspects of the life cycle. The EJB life cycle consists of just a handful of possible states. All EJBs start and end in the Does Not Exist state. At the prime of their life cycle, they are in the Ready state and can service requests. In the following sections, we’ll briefly go over the general life cycle of each type of EJB. Life cycle state and sequence diagrams are available in the official EJB specifications, which are available for downloading from Sun’s Web site at http://java.sun.com/j2ee/.
Life Cycle of a Stateless Session Bean:
A stateless session bean does not maintain state between method calls. This makes any instance of a stateless session bean interchangeable with any other instance. The stateless session bean has a simple life cycle as follows:
1. setSessionContext() is called to establish the EJB’s context.
2. ejbCreate() is called to initialize the EJB.
3. The EJB enters the ready state and can accept business method calls.
4. ejbRemove() is called to let the EJB wrap up before the end of its life cycle.
Life Cycle of a Stateful Session Bean
The life cycle of a stateful session bean is pretty much the same as that of the stateless session bean. A stateful session bean manages state between method calls. This makes the stateful session bean non-interchangeable with other instances of the same bean. As a result of this, the EJB container creates separate instances of the stateful session bean for each client. In addition, a stateful session bean must be able to handle passivation and activation. Passivation occurs when the container needs to put the EJB aside to save resources. Activation occurs when the container returns the bean to the Ready state so that it can handle business method calls again.
1. Creation is requested by the client via a create() method in the home or local home interface.
2. setSessionContext() is called to establish the EJB’s context.
3. ejbCreate() is called to initialize the EJB.
4. The EJB is in the ready stage and can take business method calls. The container can optionally passivate and activate the EJB, usually for resource-allocation purposes.
5. Removal is requested by the client via a remove() method in the home or local home interface.
6. ejbRemove() is called to let the EJB wrap up before the end of its life cycle.
Life Cycle of an Entity Bean
Entity beans continue to build on the stateful session bean life cycle by adding the Pooled state. Many containers may pool instances of session beans, but the specification doesn’t require it of the container. However, the specification does require support for pooling Entity beans. In addition, because entity beans have unique object IDs, they cannot be interchangeably pooled. This makes pooling something that must be addressed explicitly. The Pooled state sits between the Does Not Exist state and the Ready state of the entity bean. In order for this to work, the entity bean must be able to faithfully set and unset the requisite state. An Entity bean when in the pool effectively has no state. When the Entity bean is taken from the pool its state is established by assigning values from the underlying persistent store. In other words, there are no differences between pooled instances of the same entity bean. But each Entity bean in Ready state is unique. This is the contract that lets the EJB container optimize resources with entity beans. With that in mind, the entity bean life cycle looks something like this:
1. setEntityContext() is called to establish the EJB’s context. The EJB now goes into the Pooled state.
2. Creation is requested by the client via a create() method in the home or local home interface.
3. ejbCreate() is called to initialize the EJB.
4. ejbPostCreate() is called after the entity bean’s key is available. This means that code in this method can now use the context object’s getEntityObject() as well as its own getPrimaryKey().
5. The EJB is in the Ready state and can take business method calls. The container can optionally passivate and activate the EJB, which moves the entity bean back and forth from the Pooled state to the Ready state. This is usually done for resource-allocation purposes.
6. Removal is requested by the client via a remove() method in the home or local home.
7. ejbRemove() is called to let the EJB wrap up before the end of its life cycle. The entity bean is returned to the pool and enters the Pooled state.
Life Cycle of a Message-Driven Bean
Message beans serve as end points for JMS (Java Messaging Service) messages.
The message-driven bean’s life cycle is a clean and simple one, as follows:
1. setMessageDrivenContext() is called to establish the EJB’s context.
2. ejbCreate() is called to initialize the EJB.
3. The EJB enters the Ready state and is ready to accept asynchronous messages, which are handled by callbacks to the onMessage() method.
4. ejbRemove() is called to let the EJB wrap up before the end of its life cycle.
Transaction Management:
Transaction management is one of the primary tasks under the control of EJB containers. In a transactional operation, your EJB can abort by either throwing a RemoteException or using the EJB context to call setRollbackOnly(). All this is transparent to the EJB developer and works in calls that span many EJBs. Container-managed transactions are really convenient compared to having to code your own transactions. There are many choices for declarative transactional behavior ranging from NotSupported to Mandatory. If you are interested in knowing about all the sordid details, please consult the EJB specification. A good guideline to follow is that when in doubt, leave it on Required. When many EJBs interact with each other; it is all too easy to get edge cases where the transactional behavior is not consistent with what you have in mind. It’s a good idea to clearly plan out the tree of possible interactions before making a decision
Resource Management:
EJB containers also serve a critical role as the manager of resources. These resources are made available to the EJB through the context object, which is passed into the EJB during its construction. There are three different types of context objects: EntityContext, SessionContext, and MessageDrivenContext. These differ slightly, depending
on the limitations placed upon the EJB type, but are very similar for the most part. All allow lookups for container-managed resources. These resources are often mapped by the J2EE container to a local JNDI namespace,
usually bound under java:comp/env. This has the advantage of decoupling the physical resource mapping from the EJB. The context object also provides the means for the EJB to communicate with its container. It can be used to signal a transaction rollback, for example. Another valuable service is that the context object can be used to determine access privileges and call context, which is useful for specialized access control checks.
