Transaction Lock Handling
Transaction lock handling follows these rules:
Any operation that creates or frees a lock during a nest of transactions delays release of the lock until execution of the COMMIT or ROLLBACK that exits the outermost transaction in the nest. Furthermore, any lock that is promoted from SHARED lock type to EXCLUSIVE lock type during a nest of transactions delays any demotion of that lock until the exit from the outermost transaction in the nest.
This behavior is followed without exception, even in preference to subsequent rules.
Numbered or named locks that are created and freed by the MVBasic LOCK and UNLOCK statements are not incremented. You can do any number of LOCK 2 statements, but a single UNLOCK 2 statement frees lock number 2.
None of the file locks or the record locks are incremented.
If a FILE or RECORD is locked with either the SHARED or EXCLUSIVE lock type on entry to an outermost transaction, then on exit from the outermost transaction (with either a COMMIT or a ROLLBACK) that FILE or RECORD is still locked with the same lock type. Locks promoted from SHARED to EXCLUSIVE inside the transaction nest are demoted when the nest exits. Locks newly created inside the transaction nest are freed when the nest exits.
The following exceptions apply to this rule:
If a FILE was CLOSEd during the transaction, then all FILE and RECORD locks on the closed file are released on exit from the outermost transaction.
Executing either FILEUNLOCK fvar or RELEASE fvar (but not RELEASE fvar, recid) frees the file lock AND all record locks on the file referenced by fvar. If this occurs during a transaction, the locks are released when the outermost transaction exits.
Delaying unlocking until the exit of the outermost transaction is a feature of the Cache implementation. Most legacy MultiValue implementations delay unlocking only until the exit of the nested transaction level where the lock creation (or promotion) took place.