Powered by QM on a Linux server
Help and Support

KnowledgeBase 00095: Repeated Record Locks

Last updated: 27 Dec 2018
Applies to: All versions
Top level index       Full Index Search Tips
Previous article     Next article

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.

Related Articles


Please tell us if this article was helpful
Very     Slightly     Not at all
Email (optional)