WebSphere Message Brokers
File: ac00390_
Writer: Karen Cameron

Task topic

This build: July 31, 2007 21:16:32

Configuring globally coordinated message flows

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.

Before you start:

You must have completed the following tasks:

  1. Configuring databases for global coordination of transactions.
  2. Configuring global coordination of transactions (two-phase commit).
  3. Creating a message flow.
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, refer to the Transactional model in the Related links.
The following 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). You can view samples only when you use the information center that is integrated with the Message Brokers Toolkit.

To configure a message flow for global coordination:

  1. In the Message Broker Toolkit, switch to the Broker Application Development perspective.
  2. Open the message flow that you want to configure.
  3. Set the Transaction property for the following nodes if they appear in this message flow:
    • Compute node
    • Database node
    • DataDelete node
    • DataInsert node
    • DataUpdate node
    • Filter node
    • Mapping node
    • Warehouse node

    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 of the 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:
    • On distributed systems, any work that has been done to this data source in this message flow to date, including any actions taken in this node, is committed regardless of the subsequent success or failure of the message flow.
      Note: On systems other than z/OS, individual relational databases may or may not support this mode of operation.
    • z/OS platform On z/OS, actions that are taken in this node only are committed, regardless of the subsequent success or failure of the message flow. Any actions that are taken before this node, under automatic transactionality, are not committed, but remain within a unit of work, and might either be committed or rolled back, depending on the success of the message flow.
    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 type 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.

  4. Set the Transaction Mode property for the following nodes, if they appear in this message flow:
    • MQInput node
    • MQOutput node
    • MQReply node
    • SCADAInput node
    • 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:
    1. Persistence is relevant only for messages received across the WebSphere MQ Enterprise Transport, WebSphere MQ Mobile Transport, and WebSphere MQ Telemetry Transport protocols.
    2. The MQOutput or MQReply node property setting overrides the value set here.
    3. The Transaction Mode settings of the JMSInput and JMSOutput nodes are set differently to the above table.

    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.

  5. 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.
  6. Switch to the Broker Administration perspective.
  7. Add the message flow to a broker archive.
  8. 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 coordinatedTransaction to configure the message flow as globally coordinated.

    z/OS platform 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.

Related concepts
Message flows overview
Message flow transactions
The Transactional model
Related tasks
Designing a message flow
Creating a message flow
Defining message flow content
Accessing databases from message flows
Configuring globally coordinated message flows
Handling errors in message flows
Editing configurable properties
Related reference
Coordinated message flows
Built-in nodes
Supported databases
JMSInput node
JMSOutput node
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:16:33

ac00390_ This topic's URL is: