The Life Cycle of a Message-Driven Bean

The Life Cycle of a Message-Driven Bean

Just as session beans have well-defined life cycles, so does the MDB bean. The MDB instance's life cycle has two states: Does Not Exist and Method-Ready Pool . The Method-Ready Pool is similar to the instance pool used for stateless session beans.^[*] Figure illustrates the states and transitions that an MDB instance goes through in its lifetime.

^[*] Some vendors may not pool MDB instances but may instead create and destroy instances with each new message. This is an implementation-specific decision that should not affect the specified life cycle of the stateless bean instance.

The Does Not Exist State

When an MDB instance 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.

MDB life cycle

The Method-Ready Pool

MDB instances enter the Method-Ready Pool as the container needs them. When the EJB server is first started, it may create a number of MDB instances and enter them into the Method-Ready Pool. (The actual behavior of the server depends on the implementation.) When the number of MDB instances handling incoming messages 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 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 invoke the PostConstruct callback if there is one. The bean class may or may not have a method that is annotated with @javax.ejb.PostConstruct . If it is present, this annotated method will be called by the container after the bean is instantiated. This @PostConstruct annotated 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).

@MessageDriven
public class MyBean implements MessageListener {

   @PostConstruct
   public void myInit( ) {}

MDBs 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

When a message is delivered to an MDB, it is delegated to any available instance in the Method-Ready Pool. While the instance is executing the request, it is unavailable to process other messages. The MDB can handle many messages simultaneously, delegating the responsibility of handling each message to a different MDB instance. When a message is delegated to an instance by the container, the MDB instance's MessageDrivenContext changes to reflect the new transaction context. Once the instance has finished, it is immediately available to handle a new message.

Transitioning out of the Method-Ready Pool: the death of an MDB 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 by invoking an @PreDestroy callback method on the bean instance. Again, as with @PostConstruct, this callback method is optional to implement and its signature must return a void type, have zero parameters, and throw no checked exceptions. An @PreDestroy callback method can perform any cleanup operation, such as closing open resources.

@MessageDriven
public class MyBean implements MessageListener {

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

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 MessageDrivenContext 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.