3 MDBs and Messaging Models

This chapter describes the point-to-point (queue) and publish/subscribe (topic) messaging models used by JMS-based MDBs in Oracle WebLogic Server.

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

• Publish/Subscribe (Topic) Model

• Exactly-Once Processing

Point-to-Point (Queue) Model

In the point-to-point model, each message from a JMS queue is delivered to one MDB instance at a time. If a failure occurs before message acknowledgement or transaction commit, the message can be redelivered to an available MDB instance, subject to the JMS provider's redelivery and expiration settings. Redelivery does not require the same MDB instance to return.

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 a 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 deployment goes down, it will miss messages published while it is unavailable unless it is configured to use a durable subscription. 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

Use container-managed transactions with the Required transaction attribute to coordinate message receipt and participating transactional work. Redelivery can still cause repeated invocations of the MDB.

A JMS MDB can receive the same message more than once. To coordinate message receipt with transactional processing, use container-managed transactions with the Required transaction attribute. Message receipt and all transactional work in onMessage() that participates in the same transaction are committed or rolled back together. A rollback can lead to another invocation of onMessage(). Work outside that transaction is not rolled back and must tolerate repeated execution.

Redelivery is subject to the JMS provider's expiration and redelivery settings:

• If an application or server fails before message acknowledgement or transaction commit, or if the transaction rolls back, the message may be redelivered and processed again.

• Non-persistent messages can also be redelivered, but they can be lost if their JMS server shuts down or crashes.

See Configuring Transaction Management Strategy for an MDB and Redelivery and Exception Handling.