Message Processing Order

You have several options for controlling the message processing order in Java CAPS Projects:

• You can specify first-in, first out (FIFO) ordering modes, or a set of message destinations with a specific processing order, when you configure the JMS IQ Manager. See JMS IQ Manager Delivery Modes.

• You can specify message processing, either connection consumer or serial mode, at the JMS client level. See JMS Client Delivery Modes.

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.

JMS Client Delivery Modes

The delivery order options above are configured for the JMS IQ Manager. The Sun Enterprise Service Bus JMS implementation enables you to configure topic subscribers as connection consumers to improve message throughput through concurrent processing. You can set the JMS client configuration with the Concurrency property as described in Concurrency.

The use of connection consumers increases message processing performance by enabling concurrent processing using multiple threads. You can specify the number of message driven beans (MDBs) or the server session pool to assign to a JMS Collaboration to process messages concurrently. When you use connection consumer with fully concurrent or protected concurrent FIFO processing, this default setting allows the integration server to assign multiple threads to execute the Collaboration on a particular message destination.

For queues, you can also process messages concurrently using multiple integration servers; these integration servers may run on different systems.

Using a JMS client connection consumer affects the message processing order. For example, consider the scenario shown in the following figure. The JMS IQ Manager is set to fully concurrent FIFO processing. However, each Collaboration on each integration server retrieves messages as they come in, and is able to commit them unrestricted to the queue. Therefore, although the JMS IQ Manager is configured for fully concurrent FIFO processing, message order cannot be guaranteed.

Figure 1–8 Multiple Application Server Configuration

The concurrency mode affects FIFO processing in several ways. The following table lists how the JMS client concurrency mode settings affect the JMS IQ Manager FIFO mode selections for topics. For topics, only one integration server per subscriber can be used.

Table 1–4 Concurrency/FIFO Mode Interaction: Topics

Concurrency Mode	Fully Concurrent FIFO Mode
Serial mode	Fully serialized
Connection consumer	No strict order maintained

The following table lists how the JMS client concurrency mode settings affect the JMS IQ Manager FIFO mode selections for queues.

Table 1–5 Concurrency/FIFO Mode Interaction: Queues

Application Servers	Concurrency Mode	FIFO Mode
		Fully Serialized	Protected Concurrent	Fully Concurrent
Single	Serial	Fully serialized	Protected concurrent	Fully serialized
		No concurrency	No concurrency	No concurrency
	Connection consumer	Fully serialized	Protected concurrent	No strict order
		No concurrency	Concurrent	Concurrent
Multiple	Serial	Fully serialized	Protected concurrent	No strict order
		No concurrency	Concurrent	Concurrent
	Connection consumer	Fully serialized	Protected concurrent	No strict order
		No concurrency	Concurrent	Concurrent