Rocket OpenQM

 View Only

Lock enforcement in OpenQM

  • 1.  Lock enforcement in OpenQM

    ROCKETEER
    Posted 06-21-2022 07:27
    Historically, multi-value environments have been somewhat lax in enforcing use of locks when updating files. The locking system is voluntary and, if applications choose not to use locks, data integrity issues may arise. Two processes performing a read/modify/write update of the same record may overlap with one overwriting the other.

    There is a simple rule that eliminates this problem. Never write or delete a record without locking it first. This could be a simple update lock that protects the specific record or a file lock that effectively locks all records in the file.

    It is important to understand the significance of the locking system being voluntary. A badly written program that updates a record without locking it is not affected by the locks set by well written programs that follow the rules.

    This situation should never have been allowed. Attempting to write or delete a record without a lock should lead to some form of application error, however, such a rule cannot be retrospectively introduced without user agreement as programs often omit locking where a clash could not occur such as when writing a new record or when doing single user overnight tasks.

    OpenQM has a MUSTLOCK configuration parameter that, if set to 1, checks for lock protection of a record being written or deleted, taking the ON ERROR clause (or, if not present, aborting) if protection is not in place. To aid transition towards correct lock enforcement, setting this parameter to 2 logs the issue but allows the application to continue. A value of 3 is similar to mode 2 but only traps locking errors in files that use alternate key indices.

    The reason for having mode 3 of MUSTLOCK is that correct use of locking is important when using alternate key indices. Update of a single record in a data file may trigger updates to many indices. The update lock on the record is used to ensure that the index updates are grouped with the datafile update. If no lock is used, the index updates from two processes may get out of sequence resulting in the index not correctly reflecting the content of the data file.

    Locks are usually acquired by using READU to read any existing record though there are several other ways to gain a lock. Programmers frequently fail to note that a READU that takes the ELSE clause because the record does not exist still acquires the lock. The program can then go on to create the record, knowing that no other process could be creating the same new record. Where the attempt to read the record failed because, perhaps, the use mis-typed a customer number or some other item that was used as a record id, the application needs to release the unwanted lock.

    Locks are usually released as a side effect of writing or deleting the record or by use of the RELEASE statement. They are also released automatically if the file is closed.

    Applications that use transactions to group a set of updates as a single action are subject to some small but significant changes in how locking works. Firstly, updates in transactions must always be protected by a lock. Failure to comply with this rule will cause the transaction to abort. Secondly, locks are not released by the write or delete operation but are retained until the transaction commits or aborts. Converting an application to use transactions simply by inserting the appropriate transaction structures in an existing program is unlikely to be successful as the impact of the delayed release of locks must be considered. Programs that worked without transactions may result in deadlocks where two (or more) processes are waiting for each other.

    OpenQM's default behaviour is to allow deadlocks to occur. If the application gets into a deadlock, a developer can investigate the cause and hopefully resolve it quickly, Setting the DEADLOCK configuration parameter to 1 causes the program that was about to cause a deadlock to abort. There is also a mode 2 that aborts after recording the state of the locking system in a log file.

    ------------------------------
    Martin Phillips
    Rocket Internal - All Brands
    ------------------------------