The Life Cycle of a Message-Driven Bean
Because an MDB exists in the context of the WebLogic EJB container, its lifetime is also controlled by the container. An MDB initially exists in the
Does Not Exist
state in the WebLogic EJB container. At its instance creation, the bean is placed in a
state in WebLogic's EJB free pool waiting to process a message on the JMS destination (queue or topic) it's assigned to as a message listener. As shown in Figure 22.5, the following steps describe the life cycle of an MDB instance:
Figure 22.5. The life cycle of an MDB.
An MDB instance's life starts when the container calls
on the MDB class to create a new instance.
The container provides the EJB container context reference to the MDB by calling the
The container then calls
on the MDB instance to instantiate the bean to the EJB free pool (the Method Ready state). The MDB instance is then ready to receive a message sent via its assigned JMS destination by any client.
, an MDB can acquire connections to various resources, such as JMS connections. These resources are bound to the MDB as long as it remains in the Method Ready state.
When a JMS message is posted to a topic or queue, the container calls the designated MDB's
method. The bean instance in
parses and processes the message. After the method completes, the bean instance is returned to the free pool.
The MDB instance goes into the Does Not Exist state from the Method Ready state, when the container decides to reduce the number of bean instances in the free pool, either to
the allocated resources or because it no longer needs additional instances of the bean in the free pool. The WebLogic EJB container
the bean from the free pool by calling the bean's
When WebLogic Server starts, if MDBs have been deployed to the server, the WebLogic EJB container automatically instantiates multiple instances of the bean, as specified by the value of the
element in the
deployment descriptor. These bean instances are placed in the free pool, ready to service an incoming message on their assigned JMS destinations. Populating the free pool in this manner
the initial response time for the MDB because initial
for the bean can be satisfied without generating a new bean instance.
defaults to 0 if the element is not defined, which implies that WebLogic Server will not prepopulate the free pool with any MDB instances.
The EJB container creates new instances of MDBs as needed for concurrent and parallel message processing. However, the maximum number of MDB instances that can be accommodated in the free pool depends on two factors:
The value of the
element in the
deployment descriptor, which places an upper boundary on the number of MDB instances the container creates.
The number of execution threads available in WebLogic Server to service each message consumption by an MDB. For example, if
is set to 20 but only 10 execution threads are available to the EJB container, only 10 of the MDBs actually receive messages.
To learn how to configure WebLogic Server execute threads,
"The WebLogic Server Execute Queues,"
, in Chapter 28, "Performance Tuning the WebLogic Server."
The default value of the
element enables you to run beans in parallel, using as many threads as possible. The only reason to change this setting is to limit the number of beans running in parallel because of memory/processor constraints that affect the performance or operation of WebLogic Server.
Hence, when a JMS queue or topic receives a message, the WebLogic EJB container calls an associated MDB as
If a bean instance is available in the free pool, WebLogic Server uses that instance, and the message is consumed through the bean's
If no bean instances are available in the free pool because all instances of an MDB class are active and
has been reached, the message waits in the JMS destination until an MDB becomes available to
If the free pool is empty and
has not been reached, the EJB container creates a new instance of the MDB to consume the message.