|
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. |
|