KnowledgeBase 00095: Repeated Record Locks

This article describes how record locking handles repeated requests to lock the
same record within a single QM process.

Lock Types

There are two types of lock related to specific records.

An update lock (READU, RECORDLOCKU) can be held by only one process
at a time. A single process may hold locks on many different records.

A shareable read lock (READL, RECORDLOCKL) may be held by multiple
preocesses at the same time but, while anyone owns the shareable read lock, no
other process can get the update lock on the same record.

Update locks should be used whenever a record is to be added, modified or
deleted. Shareable read locks allow a process to read multiple records,
knowing that they represent a consistent view of the data in which no other
process can have changed one of the records.

There is also a file lock which gives exclusive access to the entire
file. No other process can get either type of record lock while the file lock
is owned.

Never Blocked

A fundamental concept within the locking system is that a process is never
blocked by its own locks. A program that performs two READU operations for the
same record will effectively ignore the second attempt to lock the record.
Note that there is no counter tracking the actual number of lock operations.
Only a single RELEASE or other operation that implicitly releases the lock
is needed.

Lock Promotion

A process that acquires a shareable read lock can then go on to get an
update lock on the same record, effectively promoting the power of the
lock. The READU operation will be blocked if another process also holds a
shareable read lock on the same record.

Multiple File Variables

Where the same file is opened simultaneously to multiple file variables in the
same process (typically in separate subroutines), the record lock is
associated with the file variable that was referenced in the locking operation.
The form of the RELEASE statement that takes a file variable but no record id
will release only those locks that were obtained referencing that file
variable. This behaviour is important to ensure that a subroutine does not
inadvertently release locks owned by a parent program that had also opened
the same file. Similarly, closing the file will release only the locks
associated with the specific file variable.

Use of RELEASE with both a file variable and record id will release the lock
regardless of whether it was obtained using a different file variable that
referenced the same file.

Use of RELEASE with no qualifying file variable or record id (very dangerous)
will release all record locks held by the process.