|
|
|
COMPATIBILITY NO_COMMIT_READ_LOCK
Disables commit read lock support for backward compatibility. FairCom DB V9 introduced commit read lock support as a default. Without explicit read or write locks, it is possible to have a partially updated record buffer returned in a high transaction volume environment. The returned record buffer could consist of partial old data, and partial newly updated data from a transaction commit operation from a concurrent thread. While the occurrence of this event is extraordinarily rare (on the order of one in a million record reads) it is clearly important in a high volume situation to prevent these “dirty” record reads. Commit Read Locks enable an implicit, high performance, low-level record lock ensuring consistent data record reads in high volume transaction environments.
When explicit read or write locks are enforced in the c-tree application then this feature is not required, as the transaction commits will ensure consistent data reads.
A new type of lock entry, CMT, was added to the FairCom DB Server lock table. These CMT entries are guaranteed to be very shortly held (only for the duration of the internal read operations). Under high volume server operations this new lock type may occasionally be observed as "forcei cmtlok" in a ctLOKDMP() (LockDump()) output.
Commit Read Lock Errors
An attempt to update a record without an explicit lock with the commit read logic is active results in error CMLK_ERR (768). This lock error fails the transaction commit. CULK_ERR (769) indicates an unexpected failure during the removal of a commit lock. This is an extremely rare internal FairCom DB Server error and should not be encountered in standard usage.
Performance Considerations
The commit read lock uses polling logic to permit a thread to retry a commit lock when it cannot be acquired. For example, if the updater has already acquired a write commit lock, a reader will be denied its request for a read commit lock, and the reader will retry. Particularly, for large transactions, the retries can consume a large amount of CPU time.
To avoid this high CPU utilization a more adaptive retry logic was implemented. If several retries fail in succession, the retry call is changed before each retry from a defer time of 0, to a defer time of ctredcmtdfr where ctredcmtdfr defaults to 10 milliseconds.
To provide an additional tuning mechanism for this retry value, the following configuration keyword COMMIT_LOCK_DEFER_MS <defer time in milliseconds>
The length of the defer value can be varied from zero to 100 milliseconds.
Internal tests demonstrated the effect of this change on CPU utilization was dramatic as a reader attempted to retry its read commit lock. Of course, actual performance increases will be variable, depending on any particular server environment. The trade-off with this method is introducing an unnecessary defer (i.e. if the next retry without a non-zero defer would have succeeded). In practice, this was not found to impede performance.
Commit write locks held by the transaction (i.e., locks that block read attempts during the actual commit process) are held during the entire commit. This has no direct impact upon the transaction commit, however, can cause longer delays for a read attempt when the transaction itself is comprised of a large number of write operations (e.g., committing thousands of ADDREC()s)
See Also
