Extended Locking Rules

In order to prevent another process from updating the records in a way that might make it impossible to do a rollback, the system locks any records modified during a transaction. This is done only for files that allow rollbacks. ACUCOBOL-GT offers some flexibility in record locking procedures in its transaction management system. You can enable multiple locking rules or single locking rules as the default locking mode for files that allow rollbacks.

To indicate which files will have record locks held, use the following syntax in the LOCK MODE phrase of the FILE-CONTROL entry for each affected file:

WITH  ROLLBACK

When rollback is enabled, record and file locking rules are extended. Every record updated as part of a transaction is locked until that transaction is committed or rolled back. The COMMIT and ROLLBACK verbs remove these locks. Record locks that are applied when the file is read are also kept until the end of the transaction. Multiple record locking rules are in effect by default.

Use of the compiler option, -Fl, enables single locking rules rather than multiple locking rules as the lock mode default. Normally, WITH ROLLBACK causes multiple locking rules to be in effect for a file. When -Fl is used, the WITH ROLLBACK clause does not affect whether single or multiple record locking rules are followed. Single locking becomes the default. You may enable multiple locking either by specifying WITH LOCK ON MULTIPLE RECORDS in a file's SELECT statement or by using APPLY LOCK-HOLDING ON file in the I-O CONTROL paragraph.

Record locks are held during a transaction in order to prevent another process from updating the records in a way which might make rollback impossible. Note, however, that a record may be deleted during a transaction, and another process is allowed to write a record with the same record key to the file. If this happens, the ROLLBACK will fail with a duplicate key error. See Logging and Rollback of File Update Operations for more information.

Note: During a transaction, the UNLOCK statement affects only files for which rollback is not enabled. In the case where the UNLOCK statement is ineffective because rollback was enabled for the file, the file status will be set to 00 (success).

During a transaction with a Vision or relative file, a CLOSE is postponed if any updates (WRITE, REWRITE, or DELETE) are performed on the file during the transaction, regardless of whether any records are locked. This function permits the file to remain open for ROLLBACK.

If the same physical file is OPENed again within the same transaction, even if the program is using a different logical file (different SELECT), the postponed CLOSE is canceled. Note that the mode of the original OPEN is retained. (For example, if the file were originally OPEN OUTPUT, and if the CLOSE were canceled, then an OPEN I-O on the same file within the same transaction would not enable the program to read the file.) When the second OPEN is encountered, the file position is reset to the beginning so that a READ NEXT would read the first file in the record.

CAUTION:

While a CLOSE action is delayed until the transaction is committed, a DELETE FILE action is performed immediately. If the DELETE FILE statement is contained within a transaction (before the COMMIT) following its associated CLOSE statement, the result will not be what is expected. Because the CLOSE is delayed but the DELETE FILE is executed right away, the program will attempt to delete the open file. The result of the attempted DELETE FILE action is host system dependent (for example, under Microsoft Windows, attempting to delete an open file will cause an error 37, 07 to be returned, while under UNIX, where there is no restriction on deleting an open file, the action will succeed). The safest programming practice is to not code a DELETE FILE action inside a transaction.