- Berkeley DB Reference Guide:
- Locking Subsystem
|
|
The locking subsystem is useful outside the context of Berkeley DB. It can be used to manage concurrent access to any collection of either ephemeral or persistent objects. That is, the lock region can persist across invocations of an application, so it can be used to provide long-term locking (e.g., conference room scheduling).
In order to use the locking subsystem in such a general way, the applications must adhere to a convention for naming objects and lockers. Consider the conference room scheduling problem described above. Assume there are three conference rooms and that we wish to schedule them in half-hour intervals.
The scheduling application must then select a way to identify each conference room/time slot combination. In this case, we could describe the objects being locker as bytestrings consisting of the conference room name, the date on which it is needed, and the beginning of the appropriate half-hour slot.
Lockers are 32-bit numbers, so we might choose to use the User ID of the individual running the scheduling program. To schedule half-hour slots, all the application need do is issue a lock_get call for the appropriate locker/object pair. To schedule a longer slot, the application would issue a lock_vec call with one lock_get operation per half-hour up to the total length. If the lock_vec call fails, the application would have to release the parts of the time slot that were obtained.
To cancel a reservation, the application would make the appropriate lock_put calls. To reschedule a reservation, the lock_get and lock_put calls could all be made inside of a single lock_vec call. The output of lock_stat could be post-processed into a human-readable schedule of conference room use.
|
|