Configuring global coordination of transactions (two-phase commit)

Globally coordinate message flow transactions with a transaction manager to ensure the data integrity of transactions.

Before you begin

Read Message flow transactions to understand how the integration node handles transactions. Depending on the external resource managers that the integration node accesses during the processing of its deployed message flows, you must complete the appropriate resource-dependent set of tasks to ensure that all resources are configured correctly. For example, you might have to create and configure databases, following the tasks in Working with databases.

On distributed systems, the IBM® MQ queue manager that is associated with the integration node performs the transaction manager role, which means that IBM Integration Bus requires access to IBM MQ when processing messages.

You, or your message flow developer, must also ensure that the message flows deployed to the integration node are set up to support coordination. The tasks for configuring the message flows correctly are described in Configuring transactionality for message flows.

About this task

The following external resources are able to participate in a globally coordinated message flow transaction:

  • IBM MQ queues and messages
  • CICS®
  • Databases
  • JMS providers

On distributed platforms, the default behavior of the integration node is to manage all message flow transactions by using local transactions (a one-phase commit approach). In many contexts this approach is sufficient, but if your business requires assured data integrity and consistency (for example, for audit reasons, or for financial transactions), you can configure the integration node with a local IBM MQ queue manager to manage the message flow transactions as globally coordinated (a two-phase commit approach), by using the XA protocol standard. To globally coordinate transactions, there must be a queue manager specified on the integration node, and that queue manager performs the transaction manager role. The queue manager that is specified on the integration node is used as a globally coordinated resource. Other queue managers cannot participate in the message flow transaction.

z/OS platformOn z/OS®, all transactions are globally coordinated by Resource Recovery Service (RRS), therefore the instructions in this topic do not apply. However, you must ensure that RRS is available; see Resource Recovery Service planning on z/OS. If you are connecting to CICS, you must also set the egXAForRecovery property in a configurable service; see CICSConnection configurable service.

If the connection is lost to a IBM MQ resource when the message flow is running, automatic reconnection is delayed until the inflight transaction is complete; see Configuring MQ nodes for transactions.

You configure the IBM MQ queue manager to act as the transaction manager by updating its qm.ini file, to add definitions of the additional resource managers with which you want IBM MQ to coordinate updates. Resource managers must register with the transaction manager, and there are two methods of registration:
  • Static registration: The transaction manager involves all the resource managers in a transaction that are using static registration, even if a resource manager does not have a role to play in that transaction. Therefore all resource managers that use static registration must be available for the beginning of each globally coordinated transaction, even if they are not actively participating in that transaction, otherwise the transaction fails.
  • Dynamic registration: Resource managers using dynamic registration must register with the transaction manager on a per transaction basis to get involved in a transaction (that is, if they are being updated as part of the globally coordinated transaction). A resource manager that uses dynamic registration does not need to be available for the beginning of each globally coordinated transaction.

Follow the instructions for the resource managers that are relevant in your environment and note whether they use static or dynamic registration:


  • You must specify a local queue manager on the integration node, and configured that queue manager for global transactions. You must use this queue manager only for your MQ nodes in your message flow. This restriction does not apply on z/OS; all queue managers are globally coordinated.
  • Set the node Transaction mode property to either Automatic or Yes for each node that is required in the global transaction.
    Review which Transaction mode option to set for each type of node in its node reference topic
  • Configure the BAR file to enable global transactions:
    1. Below the BAR file editor view, select the Manage and Configure tab.
    2. In the Properties view, select coordinatedTransaction.


When you have completed these steps, your message flows are processed by using global coordination, which is managed by the queue manager.

You must complete all of the steps, because if your resources are not correctly configured for global coordination the message flow will run, but transactions will not be globally coordinated.