FairCom ISAM for C

Multi-User Updates

The most significant difference between coding applications for single-user environments and multi-user environments (including local area networks) has to do with performing record updates (rewrites) and record deletions.

The basic problem is that to perform a rewrite or a deletion in a multi-user system, you must own a record lock on the record of interest. However, one must be careful to help ensure that locks are held for the shortest time possible.

There are two basic approaches to avoid prolonged data record locks:

1. In the first method, do not acquire a data record lock until the user has completed all updates on the record in a local buffer. This approach requires three record buffers: one for the current ISAM record, for which no data record lock has been requested; a second to hold the updated record; and a third to reread the current ISAM record with a LockISAM() request when the updates have been completed. If you cannot get the lock on this reread, or if the contents of the reread buffer do not agree with the contents of the original current ISAM buffer, the operator must be informed that the update could not be accomplished.
2. In the second method, acquire a data record lock when the user reads the record to begin the update process. If the updates are not completed in a specified time interval AND if the operator cannot acknowledge that updates are still desired, then release the record lock(s) and cancel the update session. This requires real-time control of the data input process, which may not be available.

Examine how the change function is used to delay getting a record lock until the rewrite or delete has actually been committed.

If either of the two above approaches is not used, then the application typically uses a scheme in which the lock is acquired when the user reads the record in preparation to update the record AND it does not relinquish the lock until the update is completed no matter how much time is required. The classic problem that arises with this technique is when an update is interrupted (say by the updater going to lunch). Then a lock is held for a (relatively) long time on the data record, blocking other users from update requests on the same record.