Scenario 1: Queue manager performs the coordination

In scenario 1, the queue manager acts as the transaction manager. In this scenario, MQI verbs control the global units of work; they are started in applications using the MQBEGIN verb and then committed using MQCMIT or backed out using MQBACK.

• 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.
• Database coordination
  When the queue manager coordinates global units of work itself, it becomes possible to integrate database updates within the units of work. That is, a mixed MQI and SQL application can be written, and the MQCMIT and MQBACK verbs can be used to commit or roll back the changes to the queues and databases together.
• Configure Db2
  Db2 support and configuration information.
• Configure Oracle
  Oracle support and configuration information.
• Configure Informix
  Informix support and configuration information.
• Sybase configuration
  Sybase support and configuration information.
• Multiple database configurations
  To configure the queue manager so that updates to multiple databases can be included within global units of work, add an XAResourceManager stanza for each database.
• Security considerations
  Considerations for running your database under the XA model.
• Considerations when contact is lost with the XA resource manager
  The queue manager tolerates database managers not being available. This means we can start and stop the queue manager independently from the database server. When contact is restored, the queue manager and database resynchronize. We can also use the rsvmqtrn command to manually resolve in-doubt units of work.
• XA dynamic registration
  The XA specification provides a way of reducing the number of xa_* calls that a transaction manager makes to a resource manager. This optimization is known as dynamic registration.

Parent topic: Transactional support scenarios