A coordinated message flow executes 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.
If you want the actions of a message flow to
be globally coordinated (that is, it must complete all processing successfully,
or complete none), ensure that your configuration supports this. For more
information about global coordination of message flow transactions, see
The Transactional model.
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).
To configure a message flow for global coordination:
- In the Message Brokers Toolkit, switch to
the Broker Application Development
perspective.
- Open the message flow that you want to configure.
- Set the Transaction property
for the following nodes if they appear in this message flow:
- Compute
- Database
- DataDelete
- DataInsert
- DataUpdate
- Filter
- Mapping
- Warehouse
You can set the Transaction property
to the following values:
- Automatic
- Any updates, deletions, and additions performed by the node are committed
or rolled back when the message flow processing completes. If the message
flow completes successfully, all changes are committed. If the message flow
does not complete successfully, all changes are rolled back.
If you want
all processing by the message flow to be coordinated, you must select this
value.
- Commit
- The action taken depends on the system to which the message flow has been
deployed:
To mix nodes with
Automatic and
Commit transactionality in the
same message flow, where the nodes operate on the same external database,
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 that are carried out by preceding
Automatic nodes.
Note: On
systems other than z/OS, individual relational
databases may or may not support this mode of operation.
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:
- Design your message flow so that uncommitted (automatic) operations do
not lock database objects that subsequent operations using a different ODBC
connection need to access.
- Configure your database's lock timeout parameter so that an attempt to
acquire a lock fails after a specified length of time. If a database operation
fails due to a lock timeout, an exception is thrown that the broker handles
in the normal way.
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.
- Set the Transaction Mode property
for the following nodes, if they appear in this message flow:
- MQInput
- MQOutput
- MQReply
- SCADAInput
- JMSInput node
- JMSOutput node
The table below provides a summary of the actions taken in response
to specific property settings for the input and output nodes.
Message persistence a |
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 b |
Any b |
Yes |
Yes |
Any b |
Any b |
No |
No |
Notes: - Persistence is relevant only for messages received across the WebSphere MQ Enterprise Transport, WebSphere MQ Mobile Transport, and WebSphere
MQ Telemetry Transport protocols.
- The MQOutput or MQReply node property setting overrides the value set
here.
- The Transaction Mode settings of the JMSInput and JMSOutput nodes are
set differently to the above table. See JMSInput node and JMSOutput node for information.
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.
- Set the Treat warnings as errors and Throw exception on database error for
each node that accesses a database to indicate how you want that node to handle
database warnings and errors. Whether you select these properties,
and how you connect the failure terminals of the nodes, also affect the way
in which database updates are committed or rolled back.
- Switch to the Broker
Administration perspective.
- Add the message flow to a broker archive.
- Select the Configure tab below the broker archive editor view and
select the message flow. This displays the configurable properties
for the message flow within the broker archive. Select the check box coordinatedTransaction to configure
the message flow as globally coordinated.
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.
The message flow is now configured for global
coordination.
Now, you can deploy the message flow to the
broker. Ensure that the broker environment (including the broker's queue manager)
and databases are correctly configured for global coordination before you
deploy the message flow.
If the broker environment and the databases are
not correctly configured for global coordination, the message flow transactions
will not be globally coordinated.