Message flow transactions

Message flows support two transaction styles:
  1. Coordinated message flows ensure that all updates to resources are committed or rolled back together within a single transaction.
  2. Uncoordinated message flows allow updates to resources to occur independently; the updates are not affected by the overall success or failure of the flow.

Coordinated message flows

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.

Updates made by a coordinated flow are committed when the flow successfully completes processing the input message. The updates are backed out if:
  1. Any node within the flow throws an exception that is not caught by a node other than the input node, and
  2. The input node’s catch terminal is not connected.

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 message flows

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).

Related concepts
Message flows overview
Related tasks
Creating a message flow
Defining message flow content
Configuring coordinated message flows
Handling errors in message flows
Related reference
Built-in nodes
Database connections for coordinated message flows
Database support for coordinated message flows