Just as the entity and 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.[41] Figure 12-4 illustrates the states and transitions that an MDB instance goes through in its lifetime.
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 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.
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 when the container invokes the
Class.newInstance( )
method on
the MDB class. Second, the
setMessageDrivenContext( ) method is invoked by the container providing the MDB
instance with a reference to its EJBContext. The
MessageDrivenContext
reference may be stored in an
instance field of the MDB.
Finally, the no-argument ejbCreate( )
method is
invoked by the container on the bean instance. The MDB has only one
ejbCreate( ) method, which takes no arguments. The
ejbCreate( ) method is invoked only once in the
life cycle of the MDB.
MDBs are
not subject to activation, so they can maintain open connections to
resources for their entire life cycles.[42] The ejbRemove( ) method should close
any open resources before the MDB is evicted from memory at the end
of its life cycle.
Once an instance is in the Method-Ready Pool, it is ready to handle
incoming messages. 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.
Bean instances leave the
Method-Ready Pool for the Does Not Exist
state when the server no longer needs them. This occurs 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 the ejbRemove( ) method on the instance.
At this time, the bean instance should perform any necessary cleanup
operations, such as closing open resources. The ejbRemove( ) method is invoked only once in the life cycle of an MDB
instance—when it is about to transition to the Does Not Exist
state. During the ejbRemove( ) method, the
MessageDrivenContext and access to the JNDI ENC
are still available to the bean instance. Following the execution of
the ejbRemove( ) method, the bean is dereferenced
and eventually garbage collected.
[41] 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.
[42] The duration of an MDB instance’s life is assumed to be very long. However, some EJB servers may actually destroy and create instances with every new message, making this strategy less attractive. Consult your vendor’s documentation for details on how your EJB server handles stateless instances.