This section describes the phases in the life cycle of a message-driven bean instance and how you can configure an MDB to control the life cycle.
A message-driven bean implements loosely coupled or asynchronous business logic in which the response to a request need not be immediate. A message-driven bean receives messages from a JMS Queue or Topic, and performs business logic based on the message contents. It is an asynchronous interface between EJBs and JMS.
All instances of a message-driven bean are equivalent—the EJB container can assign a message to any MDB instance. The container can pool these instances to allow streams of messages to be processed concurrently.
The EJB container interacts directly with a message-driven bean—creating bean instances and passing JMS messages to those instances as necessary. The container creates bean instances at deployment time and may add and remove instances during operations based on message traffic.
MDBs support concurrent processing for both topics and queues. For more information about topics and queues, see MDBs and Messaging Models.
On a WebLogic Server instance, each MDB deployment maintains one or more MDB instance pools, also known as free pools, that hold MDB instances not currently servicing requests. The maximum number of MDB instances in a free pool is controlled by the value of the max-beans-in-free-pool attribute, the number of available threads in the thread pool, the type of thread pool, and sometimes other factors. See "Tuning Message-Driven Beans" in Performance and Tuning for Oracle WebLogic Server.
The number of free pools associated with an MDB deployment depends on the type of destination the MDB deployment is connect to. Typically, an MDB deployment is associated with a single free pool on each WebLogic Server instance that hosts the deployment. However, on each WebLogic Server instance that hosts the deployment, an MDB deployment connected to a WebLogic JMS distributed destination might have one free pool for each physical destination associated with the distributed destination. The number of free pools is automatically determined by the EJB container; and, for MDBs associated with a JMS destination, each MDB free pool always corresponds to a single JMS connection.
In a queue-based JMS application (point-to-point model), each MDB instance creates a single internal JMS session and corresponds to an MDB thread.
A topic-based JMS application (the publish/subscribe model) may require a single instance, may share a single JMS session between multiple instances, or may create a session for each instance. This is automatically determined by the MDB container based on the message processing pattern specified by MDB application settings, the type of topic, the work-manager, and the max-beans-in-free-pool setting. See Chapter 10, "Configuring and Deploying MDBs Using JMS Topics." Also see "Tuning Messaging Driven Beans" in Performance and Tuning for Oracle WebLogic Server.
The default behavior for non-transactional topic MDBs is to multi-thread the message processing. There are some limitations when using:
Non-transactional topic MDBs that work with foreign (non-WebLogic) topics
Non-transactional topic MDBs that consume from a WebLogic JMS topic and process messages that have a WebLogic JMS Unit-of-Order (UOO) value
For details, see the Caution in Controlling MDB Concurrency.