FairCom ISAM for C

Data Record Lock Implementations

For non-server, multi-user implementations, the same basic steps are required for the data record DLOCK(), RLOCK(), and UDLOCK() routines as are required for the node LOCK() and UNLOCK() routines described above. If your system is not already supported by an appropriate ctclib.c, keep in mind that data record locks are NOT guaranteed to be deadlock free. Therefore, where the (node) LOCK routine can wait for a lock, since they are guaranteed deadlock free, the DLOCK() and RLOCK() routines must return immediately if a lock conflict is encountered. Error DLOK_ERR (42) signifies that another process owns a conflicting lock on the same data record.

The following three defines control locking with FairCom Standalone Multi-user applications. The model best suited for each particular operating system is defined by FairCom at compile time. To override the default, place one of the following defines at the top of ctoptn.h or in the make file that produces the ctoptn.h:

1. ctLOCK_DIRECT - lock on actual record; used for most Unix and Apple Macintosh systems.
2. ctLOCK_EXTENDED - lock on region mapped to end of file; used for most non-Unix systems.
3. ctLOCK_DUMMY - lock on region mapped to dummy lock file; used for most non-Unix systems where extensive virtual files are required.

ctLOCK_EXTENDED or ctLOCK_DUMMY are used in operating system environments not permitting a region locked for update to be read by another process. (Early versions of Windows, for example.) The use of these techniques limits the maximum amount of data stored in each file. The limits for ctLOCK_EXTENDED are discussed below. If the limit is exceeded, the lock routine returns an error code of MAPL_ERR (653).

To revert to the dummy lock file style of locking, the default for non-Unix operating systems with previous FairCom DB releases, use the ctLOCK_DUMMY define.

When either ctLOCK_DIRECT or ctLOCK_EXTENDED are used, it is not permissible for a “virtual” file to be closed when locks are pending. The ctLOKCNT define, enabled by default when using these locking methods, causes FairCom DB to counts the number of locks on each file to avoid a virtual close when locks are pending. For the same basic reason, when you save a file with locks pending you cannot rely on closing and reopening the file since pending locks would be lost.

When using the ctLOCK_EXTENDED define as an override to the default selected by FairCom for your environment, be cautioned that the FairCom DB file size extension procedure closes and reopens a file on some systems when the xtdsiz parameter is non-zero. The file closing causes errors if locks were pending on the file. If you attempt to use ctLOCK_EXTENDED when file close/reopen is used during file extension, you should receive a compile error from the ctsave.c module.

Windows does not allow one process to read a record when another process has it locked. FairCom DB supports this capability by using Extended Locking, the current default, or a “Dummy Lock File.” The following table is a summary of the advantages and disadvantages of each method. Direct locking has all of these advantages, and none of the disadvantages.

Extended Lock Strategy	Dummy Lock File
- Reduces Virtual File logic effectiveness.	+ Supports Virtual File logic.
+ Does NOT restrict file numbering.	- Restricts file numbering.
+ Makes it possible to NFS mount remote drives for data sharing purposes.	- Remote file sharing difficult due to file numbering restrictions is at best.
+ Does NOT impose artificial limits on the quantity or size of files.	- Restricts the quantity and the total size of concurrently open files.