PTF UK32212 (APAR PK57918), which exploits DB2 V8 to reduce the danger of -911 deadlocks and timeouts, should allow users to make better use of direct DB2 access to improve message throughput.
Resolving the problem
Queue management with DB2 can achieve much greater message throughput by exploiting direct connections to DB2 from MERVA transactions, so avoiding serialization on the nucleus queue management service.
But some users are not experiencing this improvement: they throttle performance by having their transactions commit each application message individually. They do this because increasing the number of messages processed per commit results in, or can result in, -911 deadlocks or timeouts.
These -911s are usually a result of contention between transactions writing to the same queue or queues. They contend for DB2 row locks in the DSLTQFUN table which are needed to allocate a QSN.
With the new version of queue management for DB2 V8, program DSLQMGD3, allocation of QSNs no longer uses locks. Other updates of the DSLTQFUN table have been moved to the MERVA nucleus so that contention no longer occurs. It is not possible to deadlock on this DB2 table. Multiple transactions can write to the same multiple target queues in any order. Also, when sharing a target queue transactions do not serialize on that queue.
In most cases we think this will allow users to process multiple messages per commit and so improve throughput and reduce overhead.
This is certainly true with 'conventional' message processing transactions which process an input queue sequentially, routing messages to the next queue or queues.
With more complex processing, where two or more transactions read messages from more than one MERVA input queue, possibly updating some of them or deleting or routing them, deadlocks are possible due to contention on input messages. (We do not think there is any advantage starting two transactions on one MERVA input queue because they compete for messages, and will thus serialize).
Note: Because DSLQMGD3 uses new DB2 capabilities introduced in V8, you can use it only if your DB2 V8 is running in new function mode. For information on how to migrate MERVA to DB2 V8, click on APAR PK57918.
Authentication in MERVA Bridge
Up to now the rule with DB2 queue management has been 'do not call the nucleus while holding locks'. This was a particular problem with MERVA Bridge if it needs to invoke the nucleus message authentication service for WBI-FN messages.
With DB2 V8 and DSLQMGD3 we think this rule can be relaxed. We have tested DSLR with authentication and COMMIT=10 in DSLKPROC and have not had any problems.
We cannot rule out problems with nucleus calls while holding locks, and we think avoiding them is a good precept, but if you need to do it you should try it out.
If you use MERVA UMRs (DSLPRM parameter UMR=YES), the above only applies if you use UMR caching. Either specify UMR caching, or turn UMRs off, otherwise DB2 table DSLTQSTAT becomes a bottle-neck for tasks adding messages to MERVA and, if they call a nucleus service while holding locks, they can deadlock with tasks using central service queue management (like MERVA Link).