The life of a session bean

The life of a session bean

 

Stateful and Stateless session beans have different life cycles. You should understand what happens during the life cycle of each.

 

Stateless beans

The life of a stateless session bean begins when the client calls the create() method of the session bean’s home interface. The container creates a new instance of the session bean and returns an object reference to the client.

 

During the creation process, the container invokes the setSessionContext() method of the Session Bean interface and calls the ejbCreate() method of the session bean implementation. The new bean object joins a pool of stateless bean objects that are ready for use by clients. Because stateless session objects don’t maintain client specific state, the container removes an object from the session bean object pool, it calls the ejbRemove() method of the bean object. Note that calling the create() or remove() methods of the home and remote/local interfaces doesn’t add or remove a stateless session bean object to or from the stateless session bean pool. The container controls the life cycle of stateless beans.

 

The life of a stateful session bean begins when the client calls the create() method of the session bean's home interface. The container creates a new instance of the session bean,  initializes it, and returns an object reference to the client.

 

During the creation process, the container invokes the setSessionContext() method of the SessionBean interface and calls the ejbCreate() method of the session bean implementation. As a bean provider , you can use these methods to initialize the session bean. The state of the session bean is now method ready, which means it can perform nontransaction operations or be included in a transaction for transaction operations. The bean remains in the method ready state until one of three things happens:

 

v The bean enters a transaction.

v The bean is removed.

v The bean is passivated.

 

When a client calls the remove() method of the remote/local or home interface, the container invokes the corresponding ejbRemove() method on the session bean object. As a bean provider, you put any application specific cleanup code in this method. After ejbRemove()  completes, the bean object is no longer usable. If the client attempts to call a method in the bean object, the container throws the java.rmi.NoSuchObjectException.

 

The container can deactivate the session bean instance. Usually this occurs for resource management reasons such as when a session object is idle for a while or if the container requires more memory. The container deactivates the bean by calling the bean's ejbPassivate() method. When a bean instance is deactivated , which is called passivation, the container stores reference information and the state of the session object on disk and frees the memory allocated to the bean. You can add code to ejbpassivate() if you have some task you want to execute just before passivation occurs. The container activates the bean object again by calling the ejbActivate() method. This occurs when the client calls a method on the session bean that is passivated. During activation, the container recreates the session object in memory and restores its state. If you want something to happen immediately after the bean becomes active again, add your code to the ejbActivate() method.

 

The method ready in transaction state

 

When a client calls a method on a session bean object in a transactional context, the container starts a new transaction or includes the bean object in an existing one. The bean enters the method ready in transaction state.

 

There are points in a transaction's life cycle , called transaction synchronization points , where a session bean object can be notified of upcoming transaction events and the object can take some action beforehand if necessary.

 

The Session Synchronization interface

 

A session bean can implement the Session Synchronization interface if it wants to be notified about the state of any transaction in which it is involved. Only stateful session beans using container managed transaction can implement SessionSynchronization. Its use is optional. The methods of SessionSynchronization  are callbacks made by the container into the bean,  and they mark points within the transaction.

 

Here is the SessionSynchronization interface:

 

public interface javax.ejb.SessionSynchroniztion

{

public abstract void afterBegin() throws RemoteException;

public abstract void beforeCompletion() throws RemoteException;

public abstract void afterCompletion (boolean completionStatus) throws RemoteException;

}

 

The following table briefly describes each method:

 

Method Description

 

Method	Description
afterBegin()	Notifies the bean instance that it is about to be used in a transaction. Any code you write within afterBegin() occur within the scope of the transaction
beforeCompletion()	Notifies the bean instance that the transaction is about to commit. If the bean has any cached values , usebeforeCompletion() to write them to the database. If necessary, a session bean could use the beforeCompletion() method to force the transaction to roll back by calling the setRollbackOnly() method of the SessionContext interface.
afterCompletion()	Notifies the bean instance that the trasaction has completed. If the transaction was committed , the parameter completionStatus is set to true. If the transaction was rolled back , the parameter is set to false.

 

 

This is how the SessionSynchronization methods are used: The client calls a transactional business method defines in the remote interface, which puts the bean object in the transaction ready state. The container calls the afterBegin() method in the bean object. Later, if the transaction is committed , the container calls beforeCompletion(), and then, if the commit was successful, the afterCompletion (true) method. If the transaction was rolled back or otherwise failed to commit, the container calls afterCompletion (false). The session bean object is now in method ready state again.