diff options
Diffstat (limited to 'docs/programmer_reference/lock_cam_conv.html')
| -rw-r--r-- | docs/programmer_reference/lock_cam_conv.html | 91 |
1 files changed, 58 insertions, 33 deletions
diff --git a/docs/programmer_reference/lock_cam_conv.html b/docs/programmer_reference/lock_cam_conv.html index a6a3c216..5ad78b9c 100644 --- a/docs/programmer_reference/lock_cam_conv.html +++ b/docs/programmer_reference/lock_cam_conv.html @@ -14,7 +14,7 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> @@ -22,9 +22,7 @@ </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="lock_twopl.html">Prev</a> </td> - <th width="60%" align="center">Chapter 16. - The Locking Subsystem - </th> + <th width="60%" align="center">Chapter 16. The Locking Subsystem </th> <td width="20%" align="right"> <a accesskey="n" href="lock_am_conv.html">Next</a></td> </tr> </table> @@ -38,51 +36,76 @@ </div> </div> </div> - <p>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.</p> - <p>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:</p> + <p> + 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. + </p> + <p> + 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: + </p> <div class="variablelist"> <dl> <dt> <span class="term">DB_LOCK_NG</span> </dt> - <dd>not granted (always 0)</dd> + <dd> + not granted (always 0) + </dd> <dt> <span class="term">DB_LOCK_READ</span> </dt> - <dd>read (shared)</dd> + <dd> + read (shared) + </dd> <dt> <span class="term">DB_LOCK_WRITE</span> </dt> - <dd>write (exclusive)</dd> + <dd> + write (exclusive) + </dd> <dt> <span class="term">DB_LOCK_IWRITE</span> </dt> - <dd>intention-to-write (shared with NG and READ, but conflicts with WRITE and IWRITE)</dd> + <dd> + intention-to-write (shared with NG and READ, but + conflicts with WRITE and IWRITE) + </dd> </dl> </div> - <p>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, <a href="../api_reference/C/dbput.html" class="olink">DB->put()</a> or <a href="../api_reference/C/dbdel.html" class="olink">DB->del()</a>). 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.</p> - <p>Applications that need to lock compatibly with Berkeley DB Concurrent Data Store must obey the -following rules:</p> + <p> + 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, + <a href="../api_reference/C/dbput.html" class="olink">DB->put()</a> or <a href="../api_reference/C/dbdel.html" class="olink">DB->del()</a>). 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. + </p> + <p> + Applications that need to lock compatibly with Berkeley DB + Concurrent Data Store must obey the following rules: + </p> <div class="orderedlist"> <ol type="1"> - <li>Use only lock modes DB_LOCK_NG, DB_LOCK_READ, DB_LOCK_WRITE, -DB_LOCK_IWRITE.</li> - <li>Never attempt to acquire a WRITE lock on an object that is -already locked with a READ lock.</li> + <li> + Use only lock modes DB_LOCK_NG, DB_LOCK_READ, + DB_LOCK_WRITE, DB_LOCK_IWRITE. + </li> + <li> + Never attempt to acquire a WRITE lock on an object + that is already locked with a READ lock. + </li> </ol> </div> </div> @@ -97,11 +120,13 @@ already locked with a READ lock.</li> <td width="40%" align="right"> <a accesskey="n" href="lock_am_conv.html">Next</a></td> </tr> <tr> - <td width="40%" align="left" valign="top">Locking with transactions: two-phase locking </td> + <td width="40%" align="left" valign="top">Locking with transactions: two-phase + locking </td> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> - <td width="40%" align="right" valign="top"> Berkeley DB Transactional Data Store locking conventions</td> + <td width="40%" align="right" valign="top"> Berkeley DB Transactional Data + Store locking conventions</td> </tr> </table> </div> |