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.
Throughout its life cycle, an MDB instance can process messages from multiple clients, although not simultaneously. It does not retain state for a specific client. 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, adding and removing instances during operation based on message traffic.
Example: In an on-line shopping application, where the process of taking an order from a customer results in a process that issues a purchase order to a supplier, the supplier ordering process could be implemented by a message-driven bean. While taking the customer order always results in placing a supplier order, the steps are loosely coupled because it is not necessary to generate the supplier order before confirming the customer order. It is acceptable or beneficial for customer orders to "stack up" before the associated supplier orders are issued.
MDBs support concurrent processing for both topics and queues. For more information about topics and queues, see MDBs and Messaging Models.
WebLogic Server maintains a free pool where MDB instances that are not currently servicing requests reside.The number of MDB instances in the 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.
Each MDB that is deployed to a server instance creates a single JMS connection.
In a queue-based JMS application (point-to-point model), each MDB instance has its own session.
In a topic-based JMS application (the publish/subscribe model), all local instances of an MDB share a JMS session. A given message is distributed to multiple MDBs—one copy to each subscribing MDB. If multiple MDBs are deployed to listen on the same topic, then each MDB receives a copy of every message. A message is processed by one instance of each MDB that listens to the topic.
The default behavior for non-transactional topic MDBs is to multi-thread the message processing. In this situation, the MDB container fails to provide reproducible behavior when the topic is not a WebLogic JMS Topic, such as unexpected exceptions and acknowledgement of messages that have not yet been processed. For example, if an application throws RuntimeException from onMessage, the container may still acknowledges the message.
Oracle recommends setting max-beans-in-free-pool to a value of 1 in the deployment descriptor to prevent multi-threading in topic MDBs when the topic is a foreign vendor topic (not a WebLogic JMS topic).