The Life Cycle of a Stateless Session Bean

The Life Cycle of a Stateless Session Bean

The life cycle of a stateless session bean is very simple. It has only two states: Does Not Exist and Method-Ready Pool. The Method-Ready Pool is an instance pool of stateless session bean objects that are not in use. Because of all the injection and such that can happen, it can be more efficient to save stateless bean instances when they are not in use. This is an important difference between stateless and stateful session beans; stateless beans define instance pooling in their life cycles and stateful beans do not.^[*] Figure illustrates the states and transitions a stateless session bean instance goes through in its lifetime.

^[*] Some vendors may not pool stateless instances but may instead create and destroy instances with each method invocation. This is an implementation-specific decision that shouldn't affect the specified life cycle of the stateless bean instance.

Stateless session bean life cycle

The Does Not Exist State

When a bean is in the Does Not Exist state, it is not an instance in the memory of the system. In other words, it has not been instantiated yet.

The Method-Ready Pool

Stateless bean instances enter the Method-Ready Pool as the container needs them. When the EJB server is first started, it may create a number of stateless bean instances and enter them into the Method-Ready Pool. (The actual behavior of the server depends on the implementation.) When the number of stateless instances servicing client requests is insufficient, more can be created and added to the pool.

Transitioning to the Method-Ready Pool

When an instance transitions from the Does Not Exist state to the Method-Ready Pool, three operations are performed on it. First, the bean instance is instantiated by invoking the Class.newInstance( ) method on the stateless bean class. Second, the container injects any resources that the bean's metadata has requested via an injection annotation or XML deployment descriptor.

You must always provide a default constructor . A default constructor is a public constructor with no parameters. The container instantiates instances of the bean class using Class.newInstance( ), which requires a no-arg constructor. If no constructors are defined, the no-arg constructor is implicit.

Finally, the EJB container will post a post-construction event. The bean class can register for this event by annotating a method with @javax.annotation.PostConstruct . This annotated method is called by the container after the bean is instantiated. The callback method can be of any name, but it must return void , have no parameters, and throw no checked exceptions. The bean class may define only one @PostConstruct method (but it is not required to do so).

@Stateless
public class MyBean implements MyLocal {

   @PostConstruct
   public void myInit( ) {}

Alternatively, you can declare your @PostConstruct method in the EJB's XML deployment descriptor:

<ejb-jar>
   <enterprise-beans>
      <session>
          <ejb-name>MyBean</ejb-name>
       <post-construct>


          <lifecycle-callback-method>myInit</lifecycle-callback-method>
          </post-construct>
      </session>
   </enterprise-beans>
</ejb-jar>

Stateless session beans are not subject to activation, so they can maintain open connections to resources for their entire life cycles.^[*] The @PreDestroy method should close any open resources before the stateless session bean is evicted from memory at the end of its life cycle. You'll read more about @PreDestroy later in this section.

^[*] The duration of a stateless bean instance's life is assumed to be very long. However, some EJB servers may actually destroy and create instances with every method invocation, making this strategy less attractive. Consult your vendor's documentation for details on how your EJB server handles stateless instances.

Life in the Method-Ready Pool

Once an instance is in the Method-Ready Pool, it is ready to service client requests. When a client invokes a business method on an EJB object, the method call is delegated to any available instance in the Method-Ready Pool. While the instance is executing the request, it is unavailable for use by other EJB objects. Once the instance has finished, it is immediately available to any EJB object that needs it. Stateless session instances are dedicated to an EJB object only for the duration of a single method call.

When an instance is swapped in, its SessionContext changes to reflect the context of the EJB object and the client invoking the method. The bean instance may be included in the transactional scope of the client's request and it may access SessionContext information specific to the client request: for example, the security and transactional methods. Once the instance has finished servicing the client, it is disassociated from the EJB object and returned to the Method-Ready Pool.

Clients that need a remote or local reference to a stateless session bean begin by having the reference injected (servlet support injection, for example), or by looking up the stateless bean in JNDI. The reference returned does not cause a session bean instance to be created or pulled from the pool until a method is invoked on it.

PostConstruct is invoked only once in the life cycle of an instance: when it is transitioning from the Does Not Exist state to the Method-Ready Pool. It is not reinvoked every time a client requests a remote reference to the bean.

Transitioning out of the Method-Ready Pool: the death of a stateless bean instance

Bean instances leave the Method-Ready Pool for the Does Not Exist state when the server no longer needs themthat is, when the server decides to reduce the total size of the Method-Ready Pool by evicting one or more instances from memory. The process begins when a PreDestroy event on the bean is triggered. The bean class can register for this event by annotating a method with @javax.annotation.PreDestroy . The container calls this annotated method when the PreDestroy event is fired. This callback method can be of any name, but it must return void , have no parameters, and throw no checked exceptions. The bean class may define only one @PreDestroy method (but it is not required to do so). An @PreDestroy callback method can perform any cleanup operations, such as closing open resources.

@Stateless
public class MyBean implements MyLocal {

   @PreDestroy
   public void cleanup( ) {
      ...
   }

Alternatively, you can declare your @PreDestroy method in the EJB's XML deployment descriptor:

<ejb-jar>
   <enterprise-beans>
      <session>
          <ejb-name>MyBean</ejb-name>
       <pre-destroy>
             <lifecycle-callback-method>cleanup</lifecycle-callback-method>
          </pre-destroy>
      </session>
   </enterprise-beans>
</ejb-jar>

As with @PostConstruct, @PreDestroy is invoked only once: when the bean is about to transition to the Does Not Exist state. During this callback method, the SessionContext and access to the JNDI ENC are still available to the bean instance. Following the execution of the @PreDestroy method, the bean is dereferenced and eventually garbage-collected.