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.
On 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.
- 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:
Procedure
Results
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.