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.