Stateful Session Bean's LifeCycle

The following state diagram shows the stateful session bean's lifecycle:

The lifecycle of a stateful session bean differs from that of a stateless session bean in a number of respects. There is no pool of identical bean instances, as each instance serves a single client. A stateful session bean transitions from a does-not-exist to a method-ready state as soon as a client performs a business interface lookup or a dependency injection of a bean. So this step is client, and not container initiated. Once a stateful session bean is in a method-ready state, the container performs the same steps as with a method-ready stateless session bean:

The container then calls a business method on the bean.

Recall that a session can involve considerable idle time if a client decides to wait, or perform other activities, between method calls. The container's cache could become full of idle stateful session bean instances. To limit such instances, the container can swap these from the cache out to disk or other storage. This process is called passivation and involves serialization of the bean instance. When the client decides to invoke a method on a passivated bean, then the container deserializes the saved state and invokes the requested method. This process is known as activation. Note that the method may not be on the original bean instance, but this is safe as at activation we restore the state which was saved at passivation.

The passivation algorithm is container-dependent, and typically is dependent on factors such as the maximum number of beans which may be held in the containers cache, the maximum bean idle time, and the victim selection policy of the container. The GlassFish victim selection policy has the following options: Least Recently Used (LRU), Not Recently Used (NRU), and First In First Out (FIFO). All of these factors can be configured by the container administrator.

The bean can provide a @PrePassivate callback method, which is executed immediately before passivation and a @PostActivate callback method, which is executed immediately after activation. A session bean's state may contain open resources such as open sockets, database or JMS connections that cannot be handled by the container during passivation. In these cases the resource will be closed in the @PrePassivate method and reopened in the @PostActivate method.

A bean can move from a method-ready state to a does-not-exist state if a @Remove annotated method is invoked. A bean can also do this if a container configured timeout period has been reached. In either case a @PreDestroy annotated method is first invoked.

A passivated bean can also move to a does-not-exist state if a timeout period has been reached. Note in this case any @PreDestroy annotated method will not be invoked.

The listing below shows a modified implementation of ShoppingCartBean with the @PrePassivate and @PostActivate callback methods added. The methods simply print out corresponding messages.

@Stateful
public class ShoppingCartBean implements ShoppingCart {
private ArrayList<String> items;
@PostConstruct
public void initialize() {
items = new ArrayList<String>();
}
public void addItem(String item) {
items.add(item);
}
public Collection<String> getItems() {
return items;
}
@PrePassivate public void logPassivation() { System.out.println( "PrePassivate method logPassivation() Invoked"); } @PostActivate public void logActivation() { System.out.println( "PostActivate method logActivation() Invoked"); }
@Remove
public void finished() {
System.out.println(
"Remove method finished() Invoked");
}
}

Note that there can be at most only one PrePassivate and one PostActivate method. The methods can take any name but must be void with no arguments.

Note that to simulate bean idle time, and hence conditions for passivation and activation, we have added a delay of 59 seconds between method calls from the Client:

public class Client {
public static void main(String args[]) throws Exception {
...
shoppingCart.addItem("Bread");
shoppingCart.addItem("Milk");
Thread.sleep(59000);
shoppingCart.addItem("Tea");
}
}

To test activation and passivation with GlassFish you will also need to log in as a container administrator and set the Max Cache Size to say 2. The Cache Resize quantity, which is the number of beans to passivate when the cache is full, is set to 2 and the Cache Idle Timeout to say 15 seconds. Then execute 3 simultaneous client sessions. This process may be different for other EJB containers.