The lifecycle of a Session Bean is different for a Stateless Session Bean and for a Stateful Session Bean.

(a) In the case of a Stateless Session Bean

The following figure illustrates the lifecycle of a Stateless Session Bean.

Figure 2-1 Lifecycle of a Stateless Session Bean

does not exist:

State when the Stateless Session Bean does not exist

method-ready pool:

State when the Stateless Session Bean exists in an executable state in the method-ready pool

(b) In the case of a Stateful Session Bean

The following figure illustrates the lifecycle of a Stateful Session Bean.

Figure 2-2 Lifecycle of a Stateful Session Bean

does not exist:

State when the Stateful Session Bean does not exist

method-ready:

State when the Stateful Session Bean is activated and exists in an executable state (no transaction) in the method-ready pool

method-ready in TX:

State when the Stateful Session Bean is activated and exists in an executable state (transaction exists) in the method-ready pool

(c) In the case of a Singleton Session Bean

The following figure illustrates the lifecycle of a Singleton Session Bean.

Figure 2-3 Lifecycle of a Singleton Session Bean

does not exist:

A state when the Singleton Session Bean does not exist

method-ready:

A state when the Singleton Session Bean is ready for execution

An EJB container initializes Singleton Session Bean. Note that you can explicitly define the initialization time during an application development, by specifying the annotation.

• To initialize a Singleton Session Bean in the starting process of an application, specify the @Startup annotation in the Singleton Session Bean class. With this, the initialization process is executed before a request is sent from an external client.
• By specifying the @DependsOn annotation, you can define the creation order of a Singleton Session Bean and other components of the Singleton Session Bean.

Once initialized, the Singleton Session Bean instance exists until the application stops. Operations of an EJB container, when a Singleton Session Bean is destroyed, are as follows:

• If the callback interceptor method that executes the PreDestroy process exists, it invokes the appropriate method. During the invocation of this method, the state is maintained so that the EJB container can use all the Beans for which the dependency is defined using DependOn.
• On the completion of the PreDestroy process, the EJB container deletes the instances of the Singleton Session Bean.

The following figure shows the lifecycle of an Entity Bean:

Figure 2-4 Lifecycle of a Entity Bean

does not exist:

State when the Entity Bean does not exist

pool:

State when the Entity Bean is passivated and exists in the passive pool

ready:

State when the Entity Bean is activated and exists in the ready pool

The following figure shows the lifecycle of a Message-driven Bean.

Figure 2-5 Lifecycle of a Message-driven Bean

does not exist:

State when the Message-driven Bean does not exist

method-ready pool:

State when the Message-driven Bean is in the method-ready state and exists in the ServerSession pool