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.

---