3 MDBs and Messaging Models

WebLogic Server MDBs can be used in either a point-to-point (queue) or publish/subscribe (topic) messaging model. These models are described in detail in "Understanding WebLogic JMS" in Programming JMS for Oracle WebLogic Server.

The following sections describe the key differences between point-to-point and publish/subscribe messaging applications.

Point-to-Point (Queue) Model: One Message Per Listener

In the point-to-point model, a message from a JMS queue is picked up by one MDB listener and stays in the queue until processed. If the MDB goes down, the message remains in the queue, waiting for the MDB to come up again.

Example: A department must update its back-end inventory system to reflect items sold throughout the day. Each message that decrements inventory must be processed once, and only once. It is not necessary for messages to be processed immediately upon generation or in any particular order, but it is critical that each message be processed.

Figure 3-1 illustrates a point-to-point application. Each message is processed by single instance of MDB_A. Message "M1" is processed by MDB_A(1), "M2" is processed by MDB_A(2), and "M3" is processed by MDB_A(3).

Figure 3-1 Point-to-Point Model

Description of Figure 3-1 follows
Description of "Figure 3-1 Point-to-Point Model"

Publish/Subscribe (Topic) Model

In the publish/subscribe model, a JMS topic publishes all messages to all subscribed listeners. If an MDB listener goes down, that MDB will miss the message, unless the topic is a durable subscription topic.

For more information on durable subscriptions and for configuration instructions, see "Setting Up Durable Subscriptions" in Programming JMS for Oracle WebLogic Server and Configuring Durable Topic Subscriptions.

Example: A financial news service broadcasts stock prices and financial stories to subscribers, such as news wire services. Each message is distributed to each subscriber.

Figure 3-2 illustrates a publish/subscribe application. In contrast to a point-to-point application, in a publish/subscribe model, a message is processed by one instance of each of the subscribing MDBs. Message "M1" is processed by an instance of MDB_A and an instance of MDB_B. Similarly, "M2" is processed by an instance of each of the subscribing MDBs.

Figure 3-2 Publish/Subscribe Model

Description of Figure 3-2 follows
Description of "Figure 3-2 Publish/Subscribe Model"

Exactly-Once Processing

An MDB pool processes each message at least once. Potentially, a message can be processed more than once:

  • If an application fails, a transaction rolls back, or the hosting server instance fails during or after the onMessage() method completes but before the message is acknowledged or committed, the message will be redelivered and processed again.

  • Non-persistent messages are also redelivered in the case of failure, except for the case where the message's host JMS server shuts down or crashes, in which case the messages are destroyed.

To ensure that a message is processed exactly once, use container-managed transactions so that failures cause transactional MDB work to rollback and force the message to be redelivered.