A message flow that includes interaction with an external database or other recoverable resource can be configured so that all 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). This means that all affected resources (queues, databases, and so on) are maintained in a consistent state, and that 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 SCADA nodes, you can set the Transaction Mode property on the nodes in the flow to Automatic; this means that messages will be part of the global transaction, and the flow marked as transactional if the input message is persistent, and uncoordinated if the input message is not persistent. Subsequent nodes in the flow which set the transaction mode property to Automatic are included in the global transaction if the flow was marked transactional by the input node.
Transaction coordination of message flows is provided on distributed platforms by WebSphere MQ and on z/OS systems by RRS. Message flows are always globally coordinated on z/OS, regardless of whether the message flow’s Coordinated property is specified as coordinated or not.
Uncoordinated flows are flows for which the Coordinated property is not set. Updates to resources used by a uncoordinated flow are managed by the separate resource managers. Some resource managers, such as WebSphere MQSeries, 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 whose scope is limited to the resources owned by a single resource manager, such as a database or queue manager.
Resource-specific transactions are typically used only when there is just one type of recoverable resource 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.) Resource-specific transactions should not be used when there is more than one resource and data integrity must be maintained.
Updates made to a resource accessed non-transactionally are committed immediately. An MQInput node configured to be non-transactional removes messages from the queue immediately, and if the flow fails the messages are lost.
Some input nodes, such as MQInput, or SCADA nodes, can be part of a transaction, depending on the persistence of the input message, by setting the transaction mode to Automatic. Messages are made part of the transaction, and the flow marked as transactional, if the input message is persistent, and non-transactional if the message is not persistent.
The Error Handler sample demonstrates the use of globally-coordinated transactions, and the differences in the message flow when database updates are coordinated (the main flow) and when they are not (the error flow).
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac00645_ |