Life Cycle of Entity Bean

There are three states in the life cycle of the entity bean, Does Not Exist, Pooled, and Ready.

When the bean is in the Does Not Exist state, no instance of the bean has been instantiated yet.

In the pooled state, several instances of the bean's implementation class are instantiated but are not associated with any EJBObject. All the bean instances in the pool are the same and are not associated with any database data or actively dealing with any client request.

Once the bean is instantiated, a reference to its javax.ejb.EntityContext is passed to it by the container using the bean's setEntityContext method.

Once the EntityContext is associated witht the bean, it can be placed in the pool. When the EJB server starts up, it will maintain a separate instance pool for each type of bean deployed by placing a number of bean instances in this pooled state.

Beans in the pooled state can be used to service ejbFindxxx requests, as these methods don't rely on the bean instance's state.

When a client requests a bean, the container creates an EJBObject for that bean, and it assigns a bean instance from any of the instances in the relevant instance pool to the EJBObject, using the appropriate data to initialize the bean.

This is done using the ejbCreate or ejbActivate method.

When a bean instance is assigned to an EJBObject, it moves to the ready state. In this state, the bean instance is associated with data and actively deals with client requests.

The bean instance can also use its EntityContext to receive information about the client that is using the instance and to receive callback methods from the container.

Initialized entity bean instances correspond to actual entries in a database, so, in the ready state, a bean instance can access a row of data from a database.

The ejbLoad and ejbStore callback methods, which the container uses to synchronize the bean's state with the database, can be called only when the bean is in the ready state.

Entity beans can move from the pooled state to the ready state in these circumstances,

• when a new entity bean instance is created using the ejbCreate method
• when the container activates a bean in response to a query using the ejbActivate method
• when the container uses ejbActivate to activate a bean that has previously been passivated.

When the bean instance is in the ready state, there may be lulls in activity when the bean instance is consumig resources but not actually dealing with a client request.

To deal with this, the EJB container can passivate the bean - that is, return the bean to the pooled state - when it's not in use. It does this by invoking the ejbPassivate method.

And if a bean instance is required again, any one of the equivalent bean instances in the pooled state can be reassigned to the EJB object.

After the client request is completed with a bean instance, the bean instance can be removed and returned to the pooled state.

When the client signals that it wants to remove a bean, the container calls the ejbRemove method on the bean instance.

The life cycle of an entity bean ends when the bean instance is removed from the pool by the container to be destroyed.

If a bean is to be released, the unsetEntityContext method is called by the container to warn the bean instance that is about to be destroyed. This allows the bean instance to discharge any data it maintains before being destroyed.