|
|
|
Inside of a transaction, an unlock request on a record behaves differently depending on whether or not the record has been updated. If it has not been updated the unlock request succeeds. If it has been updated, the unlock returns a NO_ERROR, but the lock remains and the sysiocod is set to UDLK_TRN(-3). 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(ctLOKDYNtranPersist). Or the user can make a call PUTHDR(datno,1,ctTRNPERShdr) for particular data files for which the new state will be activated. If ctLOKDYNtranPersist is not enabled, then the individual file states prevail. However, if ctLOKDYNtranPersist is enabled, the individual file states are ignored.
A call to ctLOKDYN(ctLOKDYNnopersistTran) 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. But the “tranPersist” state also affects 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,ctLOCKDFRhdr) 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,ctLOCKDFRhdr) 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.
|
|
|
When c-treeACE supports 6‑byte transaction numbers it does not display transaction overflow warnings until the current transaction number approaches the 6‑byte transaction number limit. But if 4‑byte transaction number files are in use, a key insert or delete will fail if the current transaction number exceeds the 4‑byte transaction number limit (however, c-treeACE will continue operating).
To allow a server administrator to determine when the server’s transaction number is approaching the 4‑byte transaction number limit, the following configuration option was added:
TRAN_OVERFLOW_THRESHOLD <transaction_number>
This keyword causes the c-tree Server to log the following warning message to CTSTATUS.FCS and to standard output (or the message monitor window on Windows systems) when the current transaction number exceeds the specified transaction number:
WARNING: The current transaction number (####) exceeds the user-defined threshold.
The message is logged every 10000 transactions once this limit has been reached. The TRAN_OVERFLOW_THRESHOLD limit can be set to any value up to 0x3ffffffffffff, which is the highest 6‑byte transaction number that c-treeACE supports.
