|
|
|
The Extended Lock Strategy locks a dummy, or extended, region of the data file uniquely related to the actual region. Our intent is not to lock the actual region, but to lock a uniquely related region that never has to be read. This is accomplished by adding a suitably large offset to the actual byte position of the lock. In this way, the lock is placed on the actual file involved, and no file numbering convention is required. The size of the offset must clearly exceed the largest possible actual record offset for your application.
Because the locks are held on the actual file, a file with pending locks cannot be virtually closed since the locks would be lost. This reduces the effectiveness of the Virtual File logic since not all virtual files will be available for closing.
The extended lock approach maps a lock request on an actual record to a corresponding byte at the end of the file, which cannot hold data. Based on a 2GB file size limit and our default values for ctMAX_USRLOKS, 256 the maximum of concurrent locks per each user process, and ctMAX_MBRLOKS, 1024 - the maximum number of locks which can be placed within a superfile, the extended lock approach yields the following data capacities per file:
Fixed-length data file or index file:
((2GB - (256 * 1024)) / (recSize + 1) * recSize)
For example, if recSize is 256, the data capacity is about 1.99GB, where 1GB = 1024 * 1024 * 1024.
Variable-length or superfile:
(2GB - (256 * 1024)) * 10 / 11)
This computes to about 1.81GB of data capacity. In variable-length files or superfiles part of the file is occupied by record headers maintained transparently by FairCom DB.
