"Transaction Persistent" Lock SupportBackground When a data record is locked and updated under transaction control, a subsequent unlock request while the transaction is still active returns as if it succeeded (i.e., NO_ERROR), however;
At the time of commit or abort of the transaction, the lock will be released. Savepoints can also cause the lock to be freed: if restoring to a savepoint removes all updates for the record, then the lock is freed whether or not an explicit unlock request was made and whether or not the XFREED modes are in use. The ctMARK_XFREED / ctKEEP_XFREED transaction modes (used with TRANBEG() / TRANEND() respectively), affect the commit/abort unlock behavior by only freeing locks that were explicitly freed within the transaction. A request to close a file that has been updated under transaction control has the close deferred until the transaction completes. New Behavior It is now possible to specify that locks persist even if the record has not been updated: the unlock will return NO_ERROR and sysiocod will be set to UDLK_TRN. A user can turn on this state for all files used by the user with a call to ctLOKDYN( ctLOKDNYtranPersist ). Or the user can call PUTHDR( datno, 1, ctTRNPERShdr ) for particular data files for which the new state will be activated. If ctLOKDNYtranPersist is not enabled, then the individual file states prevail. However, if ctLOKDYNtranPersist is enabled, the individual file states are ignored. A call to ctLOKDYN( ctLOKDYNnotranPersist ) will disable the user-wide state. A call to PUTHDR( datno, 0, ctTRNPERShdr ) will turn off the file state. The "tranPersist" state (whether user-wide or file specific) only affects behavior at the time an unlock request is made. Whether it is on or off at the time the lock is granted does not affect unlock behavior. A call to TRANRST() that undoes all the updates to a record causes the lock on the record to be freed. However, the "tranPersist" state also effects this behavior. If the state is on (user-wide or file-specific) at the time of the TRANRST(), then the record is not unlocked when all its updates are undone. A related issue has to do with closing a file inside of a transaction. An attempt to close a file inside a transaction that has pending record updates causes the close to be deferred until the transaction is completed. If ctLOKDYN( ctLOKDYNlockDefer ) or PUTHDR( datno, 1, ctTRNPERShdr ) are called, then the file close is deferred if there are locks pending on the file, whether or not any records are updated. ctLOKDYN( ctLOKDYNnolockDefer ) and PUTHDR( datno, 0, ctTRNPERShdr ) turn off this state. The user-wide and/or file-specific routines need only be called once. The states persist until the user logs off or the file is closed, respectively. But they can be turned on and off as the application desires. |
|||