Lock Mechanisms

There are two types of lock mechanism that can be implemented on the lock server used for the jDLS. This section describes the two lock mechanisms.

The lock mechanisms are Shared memory locking and OS file locks.

When starting the jDLS service, the default lock mechanism is Shared memory lock. The jDLS service initialisation, by default starts the jDLS Shared memory lock monitor service and jDLS Distributed lock listener service.

The jDLS Shared memory lock monitor creates a shared memory structure for the locks, which is then used for inter process communication of lock information by both jDLS lock server processes, which acquire locks on behalf of remote jBASE client processes and also local jBASE processes executing on the same system as the jDLS Lock Service. If the shared memory lock area is already allocated, then the shared memory lock group structure cannot be changed and any lock configuration options specified on the jDLS command line is ignored.

The default lock mechanism can be force to be OS file locks by inhibiting the initialisation of the jDLS Shared memory lock monitor process. If the jDLS Shared memory lock monitor service is not initialized, then the default lock mechanism will be OS file locks.

OS Lock Mechanism

To initialise the lock service without the jDLS Shared memory lock monitor, you can start the lock service using the –D option. This option causes only the jDLS Distributed lock listener service to be initialised and as such the default lock mechanism will be OS file locks. For example,

jDLS -ibD

When the jDLS Distributed lock service is active and at the same time using the OS file lock mechanism, all record locks are taken on lock files created in the /tmp/jbase subdirectory for UNIX systems and the %SYSTEMROOT%\jbase subdirectory for Windows. The file name of the lock file represents an 8 digit hexadecimal value of the inode and device numbers of the original file or pseudo file. For example,

          /tmp/jbase/jlock_xxxxxxxx_yyyyyyyy

Where xxxxxxxx is the hexadecimal value of the inode and yyyyyyyy is the hexadecimal value of the device.

To initialise the lock service to use jDLS Shared memory locking, you can use the –ib options (initialise services and run in background) on the jDLS command line. This is the default configuration for jDLS when run as a Windows Service. For example,

jDLS -ib

Shared Memory Lock Mechanism

The shared memory lock monitor process is essentially the same as the eld jRLA program, in that its sole function is to periodically examine the state of the shared memory lock table and look for orphaned locks. Orphaned locks can occur when a process exits prematurely without being able to wrap up correctly and release associated locks. These premature processes exits can be due to resource allocation, program failure or because the process has been deliberately interrupted by a fatal signal (usually signal 9) from another process. The default tidy up period is set at five minutes.

The Shared Memory Lock Monitor will scan all the locks in the shared memory lock table on a tidy up and when a suspected orphaned lock is discovered, the lock is thoroughly checked against the process identifier to ensure that the associated process is no longer in existence. If that is the case, then the lock is released, as such locks left behind by processes will automatically be cleaned up every five minutes.

It should not be necessary to clean up locks taken by remote client, which exit prematurely, as the lock server process handling locks on behalf of the client should automatically handle the lock release on detection of communication failure with the client process.

The shared memory lock table is currently only used for record locks as group locks or other binary locks are taken as OS file locks on the physical files or pseudo files in /tmp/jbase_lock or %SYSTEMROOT\jbase_lock directories.

The Shared Memory Lock Monitor can be stopped and restarted (using the –k and –ib options together with the –A option on the jDLS command line), without interfering with the Distributed Lock Listener service or the currently active lock sever processes working on behalf of remote clients. However, this action is not recommended and should only be used in extreme circumstances, as the preferred locking mechanism should be chosen prior to any local or remote client connection and the Distributed Lock Service initialized accordingly.