|Powered by QM on a Rpi server|
This article was originally published as a Tip of the Week.
A deadlock occurs when a process is waiting for a lock that will not become available until some other lock held by the process is released. Although most commonly seen with two processes waiting for each other, deadlocks can involve multiple processes.
The default behaviour of QM is to let deadlocks occur, typically bringing the application to a halt. This allows full diagnostic information to be obtained before manually recovering by logging out one of the processes. Note that, unless the process chosen to be logged out makes full use of transaction processing, there is a risk of data integrity errors as a result of killing a process in the middle of a sequence of updates.
Setting the DEADLOCK configuration parameter to 1 causes QM to check for deadlocks when a process waits for a lock. If a deadlock is found, a diagnostic message is displayed to the user and the process is aborted. The same risks of data integrity error exist as for manual recovery but, because recovery is automatic, any other related recovery actions for partial updates will not be done.
Deadlocks are totally avoidable by careful programming. Where multiple records must be locked simultaneously, adhering to a fixed sequence in which they will be locked makes deadlocks impossible.
Another possible avoidance method is for programs to use the LOCKED clause to operations that obtain locks and, if blocked by another used, release all locks and start the update sequence again.