Cache Locks Test

Cache locks are created when a Cache process issues a Lock command on a Cache 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 CacheLocks test 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.

Target of the test : A Cache Database server

Agent deploying the test : An internal/remote agent

Outputs of the test : One set of results for every InstanceName configured

Configurable parameters for the test
  1. TEST PERIOD – How often should the test be executed
  2. Host – The IP address of the Cache database server
  3. Port – The port on which the server is listening
  4. INSTANCEDIRECTORY - Typically, the Cache console log file will be available in the install directory of a Cache instance. Therefore, in the INSTANCEDIRECTORY text box, specify the name of the instance being monitored and the install directory that holds the Cache console log file of that instance, in the following format: InstanceName:InstallDirectory. In case you want to monitor the console log files pertaining to multiple Cache instances, then provide a comma-separated list of InstanceName:InstallDirectory pairs in the INSTANCEDIRECTORY text box. For example: CACHEWEB:d:\Intersystems\CacheWeb,CACHE2:d:\Intersystems\Cache2.
  5. To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

    The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

    • The eG manager license should allow the detailed diagnosis capability
    • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Lock entries:

Indicates the current number of locks on this Cache instance.


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, the lock type.

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.

The lock type/mode can be any one of the following:

Type of Lock Description


Exclusive lock mode


Share lock mode


ZALLOCATE lock mode


Waiting for exclusive lock mode


Waiting for share lock mode


Waiting for ZALLOCATE lock mode


Exclusive lock pending, waiting for server to grant the exclusive lock


Share lock pending, waiting for server to grant the share lock


Delock pending, waiting for server to release the lock


Lock lost due to network reset