You can configure a message flow that includes interaction with an external database or other recoverable resource so that all of its processing is coordinated within a single, global, transaction. This coordination ensures that either all processing is successfully completed, or no processing is completed. The transaction is committed (if all processing is successful), or rolled back (if at least one part of the processing is unsuccessful). Therefore, all affected resources (queues, databases, and so on) are maintained in a consistent state, and data integrity is preserved.
To configure a message flow as coordinated, set the Coordinated property on the message flow.
For some input nodes, such as MQInput or SCADAInput nodes, set the Transaction Mode property on the nodes in the flow to Automatic. The Automatic option makes messages part of the global transaction, and marks the message flow as transactional if the input message is persistent, or uncoordinated if the input message is not persistent. Subsequent nodes in the flow that set the Transaction Mode property to Automatic are included in the global transaction if the flow is marked transactional by the input node.
Transaction coordination of message flows is provided on distributed systems by WebSphere MQ, and on z/OS systems by RRS. Message flows are always globally coordinated on z/OS, regardless of the setting of the message flow’s Coordinated property.
Uncoordinated flows are flows for which the Coordinated property is not set. Updates to resources that are used by a uncoordinated flow are managed by the separate resource managers. Some resource managers, such as WebSphere MQ, allow updates to be made non-transactionally, or as part of a resource-specific transaction. Other resource managers, such as database managers, always use a resource-specific transaction. A resource-specific transaction is a transaction with a scope that is limited to the resources that are owned by a single resource manager, such as a database or queue manager.
Resource-specific transactions are typically used when only one type of recoverable resource is used in a flow. An example of such a flow is one that contains an MQInput and an MQOutput node, but which does not access any databases. Do not use resource-specific transactions when more than one resource exists and data integrity must be maintained.
Updates that are made to a resource that is accessed non-transactionally are committed immediately. An MQInput node that is configured to be non-transactional removes messages from the queue immediately; if the flow fails, the messages are lost.
Set the Transaction Mode property to Automatic to make some input nodes (such as MQInput or SCADAInput) part of a transaction, depending on the persistence of the input message. If the input message is persistent, messages are made part of the transaction, and the flow is marked as transactional. If the message is not persistent, the flow is marked as non-transactional.