eG Monitoring
 
Measures reported by CacheLocksTest

Caché locks are created when a Caché process issues a Lock command on a Caché entity, such as a local or global variable, as long as the entity is not already locked by another process. Periodic monitoring of the locking activity on every Cache instance is imperative to ensure that no application-critical Cache entity is locked, as this can sometimes cause serious application errors. Similarly, the number of locks used by a Cache system can also impact Cache performance. Besides the number, it would be good practice to keep an eye out for the lock type too, so that potentially dangerous lock types are detected and released in time. The CacheLocksTest that the eG agent executes on a Cache server serves all the above-mentioned purposes. This test reports the number of locks on every Cache instance, and additionally reveals the lock type, reference, and owner of the lock, so as to aid further diagnosis.

Measurement Description Measurement Unit Interpretation
Lock_entries The current number of locks on this Cache instance Number If the value of this measure is very high or is increasing consistently, then you might have to enlarge the size of the lock table. Also, you might want to view the detailed diagnosis of this measure, so that you can determine the process that is holding each of the locks, the lock reference, and most importantly, a lock type. The lock type/mode can be any one of the following:
Type/Mode of the Lock Description
Exclusive Exclusive lock mode
Shared Share lock mode
LockZA ZALLOCATE lock mode
WaitLock Waiting for exclusive lock mode
WaitShare Waiting for share lock mode
WaitLockZA Waiting for ZALLOCATE lock mode
LockPending Exclusive lock pending, waiting for server to grant the exclusive lock
SharePending Share lock pending, waiting for server to grant the share lock
DelockPending Delock pending, waiting for server to release the lock
Lost Lock lost due to network reset

An 'incremental lock', for instance, is potentially dangerous because it can lead to a situation known as "deadlock". This situation occurs when two processes each assert an incremental lock on a variable already locked by the other process. Because the attempted locks are incremental, the existing locks are not released. As a result, each process hangs while waiting for the other process to release the existing lock.