Distributed Lock Information

Although the lock mechanisms keeps track of outstanding locks taken by processes or even threads in case of the shared memory lock table, this information is relatively limited and usually insufficient to easily determine lock ownership. This section details about the lock information in jDLS.

In case of OS file locks, all that is retrieval is the process id of the process, which has taken the lock and maybe the device and inode of the file or stub file. The shared memory mechanism provides additional independent information in the lock table such as port number, record key and thread id. Unfortunately, the record key alone is not usually enough for lock diagnosis and additional information such as the file or table information is also usually required. Finding the filename associated with an inode may not be simple for some platforms and in later Multiple Application Servers implementations, which will not use stub files this information will be unavailable.

The only process that knows the application file or table name and other associated information is usually the client process, as this was the process that opened or referenced the file or table and obtained the variable on which to take or release locks.

As such when using distributed locking, the internal client lock and file or table information is periodically written out to a native file using the port number for the process. This port information is written to the JBCRELEASEDIR/proc/info directory of the lock server system.

In case of remote clients, the information is sent to the associated lock server processes, which in turn write the data with appended statistics into the info directory on behalf of the client process.

In case of local processes, executing on the same system as the jDLS lock service, these processes write their lock and file information directly into the JBCRELEASEDIR/proc/info directory. This information can then be retrieved, interpreted and displayed by the lock and file utilities, such as SHOW-ITEM-LOCKS and LIST-OPEN-FILES. This procedure is also a change to the polling procedure done by the utilities that would otherwise occur when not using jDLS, as it is not possible to use shared memory between Multiple Application Servers.

The client or local processes only write lock information when the lock information has changed and the process is either initialised, blocking on a lock, no longer waiting on a blocked lock, about to get input or about to sleep. As such, the lock information can only be used to provide a snapshot of the lock or open file status for the Multiple Application Server processes at any point in time. The lock information is deleted on process exit even if the process exit abnormally.