Isolation level

In IBM MQ, a message on a queue might be visible before a database update, depending on the transaction isolation design implemented within the database.

When an IBM MQ queue manager is working as an XA transaction manager, to coordinate updates to XA resource managers, the following commit protocol is followed:
  1. Prepare all XA resource managers.
  2. Commit the IBM MQ queue manager resource manager.
  3. Commit other resource managers.

Between step 2 and 3, an application might see a message that is committed to the queue but the corresponding row in the database does not reflect this message.

This is not a problem if the database is configured such that the application's database API calls wait for pending updates to be completed.

We can resolve this by configuring the database differently. The type of configuration needed is referred to as the "isolation level". For more information on isolation levels, refer to the database documentation. We can, alternatively, configure the queue manager to commit the resource managers in the following reverse order:
  1. Prepare all XA resource managers.
  2. Commit other resource managers.
  3. Commit the IBM MQ queue manager resource manager.

When we change the protocol the IBM MQ queue manager is committed last, so applications that read messages from the queues see a message only after the corresponding database update has been completed.

To configure the queue manager to use this changed protocol, set the AMQ_REVERSE_COMMIT_ORDER environment variable.

Set this environment variable in the environment from which the strmqm is run to start the queue manager. For example, run the following in the shell just before starting the queue manager: 
export AMQ_REVERSE_COMMIT_ORDER=1
Note: Setting this environment variable might cause an extra log entry per transaction, so this will have a small impact on the performance of each transaction. Parent topic: Scenario 1: Queue manager performs the coordination