Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 16. - The Locking Subsystem -	Chapter 16. The Locking Subsystem	Next

@@ -38,51 +36,76 @@

The Berkeley DB Concurrent Data Store product has a simple set of conventions for locking. It -provides multiple-reader/single-writer semantics, but not per-page -locking or transaction recoverability. As such, it does its locking -entirely in the Berkeley DB interface layer.

The object it locks is the file, identified by its unique file number. -The locking matrix is not one of the two standard lock modes, instead, -we use a four-lock set, consisting of the following:

+ The Berkeley DB Concurrent Data Store product has a simple + set of conventions for locking. It provides + multiple-reader/single-writer semantics, but not per-page + locking or transaction recoverability. As such, it does its + locking entirely in the Berkeley DB interface layer. +

+ The object it locks is the file, identified by its unique + file number. The locking matrix is not one of the two standard + lock modes, instead, we use a four-lock set, consisting of the + following: +

DB_LOCK_NG: not granted (always 0); + not granted (always 0) +
DB_LOCK_READ: read (shared); + read (shared) +
DB_LOCK_WRITE: write (exclusive); + write (exclusive) +
DB_LOCK_IWRITE: intention-to-write (shared with NG and READ, but conflicts with WRITE and IWRITE); + intention-to-write (shared with NG and READ, but + conflicts with WRITE and IWRITE) +

The IWRITE lock is used for cursors that will be used for updating -(IWRITE locks are implicitly obtained for write operations through the -Berkeley DB handles, for example, DB->put() or DB->del()). While -the cursor is reading, the IWRITE lock is held; but as soon as the -cursor is about to modify the database, the IWRITE is upgraded to a -WRITE lock. This upgrade blocks until all readers have exited the -database. Because only one IWRITE lock is allowed at any one time, no -two cursors can ever try to upgrade to a WRITE lock at the same time, -and therefore deadlocks are prevented, which is essential because Berkeley DB Concurrent Data Store -does not include deadlock detection and recovery.

Applications that need to lock compatibly with Berkeley DB Concurrent Data Store must obey the -following rules:

+ The IWRITE lock is used for cursors that will be used for + updating (IWRITE locks are implicitly obtained for write + operations through the Berkeley DB handles, for example, + DB->put() or DB->del()). While the cursor is reading, the IWRITE + lock is held; but as soon as the cursor is about to modify the + database, the IWRITE is upgraded to a WRITE lock. This upgrade + blocks until all readers have exited the database. Because + only one IWRITE lock is allowed at any one time, no two + cursors can ever try to upgrade to a WRITE lock at the same + time, and therefore deadlocks are prevented, which is + essential because Berkeley DB Concurrent Data Store does not + include deadlock detection and recovery. +

+ Applications that need to lock compatibly with Berkeley DB + Concurrent Data Store must obey the following rules: +

Use only lock modes DB_LOCK_NG, DB_LOCK_READ, DB_LOCK_WRITE, -DB_LOCK_IWRITE.
Never attempt to acquire a WRITE lock on an object that is -already locked with a READ lock.
+ Use only lock modes DB_LOCK_NG, DB_LOCK_READ, + DB_LOCK_WRITE, DB_LOCK_IWRITE. +
+ Never attempt to acquire a WRITE lock on an object + that is already locked with a READ lock. +