Solution: You can disable next key locking by typing the
following command in a DB2 command window,
and restarting the DB2 database manager:
If you have
written your message flows so that the AggregateRequest and AggregateControl
nodes are contained within separate message flows, the message flows being
used have at least two threads that are accessing the same database table:
- AggregateRequest node: creates new rows in the database as messages are
sent out.
- AggregateControl node: updates existing rows as messages are received,
then removes groups of rows after an aggregation group is finished.
If there is a second set of aggregation flows, these also use
the same table.
If DB2_RR_TO_RS is not set, it is possible that one
AggregateReply thread's updates will lock the next row in the database (a DB2 optimization). AdditionalInstances are
threads available to process a message flow on any of its input nodes, in
addition to the minimum number created. If there is only one aggregation flow
in total, there might not be a problem. However, when you introduce multiple
aggregate flows, deadlocks are possible (even without additional instances).
Use
DB2_RR_TO_RS if aggregation is being used. The exception to this is if you
have only one aggregation flow for each broker with no additional instances,
and the message throughput is low.