Handling exceptions and database deadlocks in aggregation flows

When you use aggregation flows, you might find that exceptions or database deadlocks occur. This topic tells you how to deal with them.

Before you start:

To complete this task, you must have completed the following tasks:

Dealing with exceptions

If an error is detected downstream of an AggregateReply node, the broker throws an exception. Another node in the message flow might also throw an exception using the ESQL THROW statement. In either case, when an exception is thrown, it is caught in one of two places:

  • The input node on which the replies arrive
  • The AggregateReply node

The following table lists events and what happens to an exception thrown downstream of the AggregateReply node.

Event Message propagated Output terminal Exception caught at
An expected reply arrives at the input node and is passed to the In terminal of the AggregateReply node. It is the last reply needed to make an aggregation complete. Aggregated reply message containing all the replies Out Input node
An unexpected reply arrives at the input node and is passed to the AggregateReply node. It is not recognized as a valid reply, and the Unknown Message Timeout property is set to 0. Message received Unknown Input node
A timeout occurs because all the replies for an aggregation have not yet arrived. Aggregated reply message containing all the replies that have been received Timeout AggregateReply node
An unknown timeout occurs because a retained message was not identified as a valid reply. Retained message Unknown AggregateReply node
An aggregation is discovered to be complete at some time other than when the last reply arrived. Aggregated reply message containing all the replies Out AggregateReply node

If you want to handle errors that occur in aggregation flows, you must catch these exceptions at all instances of each of these nodes in the message flow. To do this:

  1. Switch to the Broker Application Development perspective.
  2. Open the message flow that you want to work with.
  3. If you want to handle these exceptions yourself, connect the catch terminal of each input and AggregateReply node to a sequence of nodes that handles the error that has occurred.

    If you want a unified approach to error handling, attach the catch terminals of all these nodes to a single sequence of nodes, or create a subflow that handles errors in a single consistent manner and attach that subflow to each catch terminal.

  4. If you want the broker to handle these exceptions using default error handling, do not connect the catch terminals of these nodes.
If you connect the catch terminal of the AggregateReply node, and want to output the message propagated through this terminal to a destination from which it can be retrieved for later processing, you must include a Compute node in the catch flow to provide any transport-specific processing. For example, you must add an MQMD header if you want to put the message to a WebSphere MQ queue from an MQOutput node.

The ESQL example below shows you how you can add an MQMD header and pass on the replies received by the AggregateReply node:

-- Add MQMD
SET OutputRoot.MQMD.Version = 2;
.
-- Include consolidated replies in the output message
SET OutputRoot.XML.Data.Parsed = InputRoot.ComIbmAggregateReplyBody;
.

If you want to propagate the information about the exception in the output message, you must also set the Compute mode property of the Compute node to a value that includes Exception.

Dealing with database deadlocks

The AggregateRequest and AggregateReply nodes access the broker database to write and read information related to aggregated request processing in the table BAGGREGATE. Deadlocks can occur when multiple resources attempt to access database tables simultaneously.

To prevent database deadlock:

  1. If you are creating a broker database using Sybase on a distributed system, or DB2 on z/OS, the default locking setting is page locking. This setting can result in deadlocks within aggregation flows. When you configure broker database for a broker that will host aggregation message flows, either when you create the database or at a later time, enable row locking to avoid potential deadlocks.
  2. If you are creating a broker database using DB2 on a distributed system, the broker might experience deadlocks if the DB2 next key locking feature is enabled. The deadlock situation is reported by the broker, which writes the event log message BIP2322 with SQL State 40001.

    If this problem occurs, disable next key locking by typing the following in a DB2 command window:

    db2set DB2_RR_TO_RS=YES

    When this command completes, restart the DB2 database manager. This command does not have any other effect on the operation of this database.

If you are using another database, these deadlocks do not occur.

Related concepts
Message flows
Message flow aggregation

Related tasks
Configuring aggregation flows
Creating the aggregation fan-out flow
Creating the aggregation fan-in flow
Associating fan-out and fan-in aggregation flows
Setting timeouts for aggregation
Using multiple AggregateControl nodes
Handling errors in message flows
Designing a message flow
Creating a message flow
Defining message flow content

Related reference
AggregateControl node
AggregateReply node
AggregateRequest node