If you want to coordinate the message flow processing with other resources, you must configure properties both of the nodes within the message flow and of the message flow itself.
Before you start:
To complete this task, you must have completed the following task:
A coordinated message flow must execute within a single transaction, which is started when a message is received by an input node, and can be committed or rolled back when all processing has completed. You can also control how database errors are handled by the node that interacts with the database.
To configure the message flow and the nodes:
You can set the Transaction property to the following values:
If you want all processing by the message flow to be coordinated, you must select this value.
If you want to mix nodes with Automatic and Commit transactionality in the same message flow, where the nodes operate on the same external database, you must use separate ODBC connections: one for the nodes that are not to commit until the completion of the message flow, and one for the nodes that are to commit immediately. If you do not, the nodes that commit immediately will also commit all operations carried out by preceding Automatic nodes.
If you define more than one ODBC connection you might get database locking problems. In particular, if a node with Automatic transactionality carries out an operation, such as an INSERT or an UPDATE, that causes a database object (such as a table) to be locked, and a subsequent node tries to access that database object using a different ODBC connection, an infinite lock (deadlock) occurs.
The second node waits for the lock acquired by the first to be released, but the first node will not commit its operations and release its lock until the message flow completes; this will never happen because the second node is waiting for the first node's database lock to be released.
Such a situation cannot be detected by any DBMS automatic deadlock-avoidance routines because the two operations are interfering with each other indirectly, using the broker.
There are two ways to avoid this sort of locking problem:
For information concerning which database objects are locked by particular operations, and how to configure your database's lock timeout parameter, consult your database product documentation.
The table below provides a summary of the actions taken in response to specific property settings for the input and output nodes.
Message persistence 1 | Input node Transaction Mode | MQOutput or MQReply node Transaction Mode | Message flow is globally coordinated |
---|---|---|---|
Yes | Yes | Automatic | Yes |
No | Yes | Automatic | Yes |
Yes | No | Automatic | No |
No | No | Automatic | No |
Yes | Automatic | Automatic | Yes |
No | Automatic | Automatic | No |
Any 2 | Any 2 | Yes | Yes |
Any 2 | Any 2 | No | No |
Notes:
|
The default on each input node is Yes, which means that the incoming messages are processed under syncpoint. In addition, messages sent to the output node are delivered under syncpoint. You can change this behavior if the output node is an MQOutput or MQReply node, both of which have a Transaction Mode property.
If you set the Transaction Mode on an input node to Automatic, the incoming messages are processed under syncpoint only if they are defined as persistent. Messages sent to the MQOutput node are delivered under syncpoint unless you explicitly change the Transaction Mode in the MQOutput node.
On z/OS, transactions are always globally coordinated. The setting of the coordinatedTransaction property for a message flow is ignored. Coordination is always provided by RRS.
Related concepts
Message flows
Related tasks
Accessing databases from message flows
Configuring coordinated message flows
Handling errors in message flows
Editing configurable properties
Related reference
Supported databases
Built-in nodes
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac00393_ |