3 MDBs and Messaging Models

Understand the different models for for MDBs. Oracle WebLogic Server MDBs are used in either a point-to-point (queue) or publish/subscribe (topic) messaging model.

These models are described in detail in Developing JMS Applications for Oracle WebLogic Server

This chapter includes the following sections:

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

• Publish/Subscribe (Topic) Model

• Exactly-Once Processing

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 Point-to-Point Model"

Publish/Subscribe (Topic) Model

In the publish/subscribe model, a JMS topic publishes a copy of each message to each logical subscription. A logical subscription consists of one or more physical subscriptions, where each physical subscription is associated with a different member of a distributed topic.

For stand-alone (non-distributed) topics, a logical subscription always consists of a single physical subscription on the topic. If an MDB goes down, that MDB will miss the message, unless the topic is a durable subscription topic. For information on durable subscriptions and for configuration instructions, see Setting Subscription Durability.

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 copy of the message is processed for each of the logical subscriptions. In this diagram, there are two logical subscriptions, where each logical subscription consists of a separate physical subscription on the single topic. MDB_A has two instances that process the messages for a single dedicated subscription. Similarly, MDB_B has two instances that process the messages for a different single dedicated subscription. Message M1 is processed by an instance of MDB_A and an instance of MDB_B. Similarly, message M2 is processed by an instance of each of the subscribing MDBs.

Figure 3-2 Publish/Subscribe Model

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

Exactly-Once Processing

An MDB application processes each message at least once. To ensure that a message is processed exactly once, use container-managed transactions, so that failures cause transactional MDB work to roll back and force the message to be redelivered.

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 when the message's host JMS server shuts down or crashes, in which case the messages are destroyed.