Library Version 11.2.5.3

Library Version 12.1.6.1

- + - +

Locking and non-Berkeley DB applications			Locking and non-Berkeley DB + applications
Prev	Chapter 16. - The Locking Subsystem -	Chapter 16. The Locking Subsystem	Next

@@ -34,38 +33,50 @@

Locking and non-Berkeley DB applications

Locking and non-Berkeley DB + applications

The Lock 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 (for example, conference room scheduling).

In order to use the locking subsystem in such a general way, the -applications must adhere to a convention for identifying objects and -lockers. Consider a conference room scheduling problem, in which there -are three conference rooms scheduled 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 locked as bytestrings consisting of the conference -room name, the date when 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 needs to do is issue a DB_ENV->lock_get() call -for the appropriate locker/object pair. To schedule a longer slot, the -application needs to issue a DB_ENV->lock_vec() call, with one -DB_ENV->lock_get() operation per half-hour — up to the total length. If -the DB_ENV->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 -DB_ENV->lock_put() calls. To reschedule a reservation, the -DB_ENV->lock_get() and DB_ENV->lock_put() calls could all be made inside of -a single DB_ENV->lock_vec() call. The output of DB_ENV->lock_stat() could -be post-processed into a human-readable schedule of conference room -use.

+ The Lock 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 + (for example, conference room scheduling). +

+ In order to use the locking subsystem in such a general way, + the applications must adhere to a convention for identifying + objects and lockers. Consider a conference room scheduling + problem, in which there are three conference rooms scheduled + 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 + locked as bytestrings consisting of the conference room name, + the date when 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 needs to do is + issue a DB_ENV->lock_get() call for the appropriate locker/object pair. + To schedule a longer slot, the application needs to issue a + DB_ENV->lock_vec() call, with one DB_ENV->lock_get() operation per half-hour + — up to the total length. If the DB_ENV->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 DB_ENV->lock_put() calls. To reschedule a reservation, the + DB_ENV->lock_get() and DB_ENV->lock_put() calls could all be made inside of a + single DB_ENV->lock_vec() call. The output of DB_ENV->lock_stat() could be + post-processed into a human-readable schedule of conference + room use. +