JMS IQ Manager Delivery Modes

For a single consumer with a single process, processing for queues is fully serialized, by default. The process of processing a message is as follows:

1. The receiver requests, or is ready to receive, a message

2. The receiver receives the message

3. The receiver processes the message

When multiple receivers or multiple processes within a single receiver subscribe to the same message destination (queues only), you have a choice of three first-in, first-out (FIFO) delivery modes, as listed below. These ordering modes apply globally to all queues in the Java CAPS Project

• Fully concurrent

  Receivers can retrieve messages when all older messages have been received, or are being received, and can commit messages in any order (without using time sequence).

• Protected concurrent

  Receivers can retrieve messages when all older messages have been received or are being received, but must commit using time sequence.

• Fully serialized

  Receivers read a messages only after all messages have been received and commit messages using a time sequence.

Fully Concurrent Processing

In fully concurrent mode, receivers can retrieve messages from a destination only when all older messages have been received or are in the process of being received. Receivers can then commit messages without restrictions. By default, JMS IQ Managers use fully concurrent processing for queues.

Figure 1–5 Fully Concurrent Processing

The figure above shows a sample delivery sequence for fully concurrent processing. In steps 1 and 2, the receivers retrieve their messages from the input queue. Both receivers must wait until each consumer has retrieved its messages, or is in the process of retrieving them, before they are able to commit messages to the output destination.

As steps 3 and 4 infer, receivers can commit messages in any order; therefore, messages can be committed out of sequence, which might not be acceptable. For example, a patient release record may be committed before the patient admittance record is committed. The following table indicates the benefits and drawbacks of fully concurrent processing.

Table 1–1 Tradeoffs for Fully Concurrent Processing

Benefits	Drawbacks
Provides the highest performance.	Delivery is not time-sequenced.
Receivers are not hampered by other receivers.

Protected Concurrent Processing

In protected concurrent mode, receivers retrieve messages just as in fully concurrent mode, after all messages have been received or are being received. Messages can only be committed, however, if all older messages have previously been committed.

Figure 1–6 Protected Concurrent Processing

The figure above shows a sample delivery sequence for protected concurrent processing. In steps 1 and 2, the receivers retrieve their messages from the input queue. Both receivers must wait until each consumer has retrieved, or is in the process of retrieving, its messages before being able to commit messages to the output destination. ReceiverB might be ready to commit its message before ReceiverA, but must wait until ReceiverA commits its message (step 3). Only when ReceiverA’s message has been committed, can ReceiverB commit its message (step 4).

Protected concurrent processing thus is a more workable solution in a scenario where a Project deals with messages such as patient records, where the admittance record must be committed before the release record.

The following table shows the benefits and drawbacks of protected concurrent processing.

Table 1–2 Tradeoffs for Protected Concurrent Processing

Benefits	Drawbacks
Provides better performance than serialized processing.	Provides lower performance than fully concurrent processing.
Messages are delivered by time sequence.

You specify protected concurrent processing for JMS IQ Managers with the Protected Concurrent Queues property as described in Special FIFO Mode Properties.

---

Note –

By design, protected concurrent FIFO works only within one transaction, either in the form of one session or in the form of one XA transaction on the same server. You should always use XA when using the protected concurrent FIFO mode with a message-driven bean (MDB), since Java CAPS does not support single sessions with MDBs.

---

Fully Serialized Processing

In fully serialized mode, receivers can only retrieve messages after all older messages have been received and committed.

Figure 1–7 Fully Serialized Processing

The figure above shows a sample delivery sequence for serialized processing. In step 1, ReceiverA retrieves its message. ReceiverB might at this point be ready to receive its message, but must wait until ReceiverA has committed its message. After ReceiverA commits the message in step 2, ReceiverB can then retrieve and commit its message (steps 3 and 4).

The following table shows the benefits and drawbacks of protected concurrent processing.

Table 1–3 Tradeoffs for Fully Serialized Processing

Benefits	Drawbacks
Guaranteed delivery by time sequence.	Provides the lowest performance of all FIFO modes.

You specify fully serialized processing for JMS IQ Managers with the Fully Serialized Queues property as described in Special FIFO Mode Properties.

Serial Processing Across a Destination Group

You can also specify delivery order specifically for a set of topics and queues (time order groups). For these groups, consumers can only receive messages when all other messages in the time order group have been received or are in the process of being received. For information on specifying a time order group, refer to Time Dependency Properties.