diff options
| author | Lorry Tar Creator <lorry-tar-importer@baserock.org> | 2015-02-17 17:25:57 +0000 |
|---|---|---|
| committer | <> | 2015-03-17 16:26:24 +0000 |
| commit | 780b92ada9afcf1d58085a83a0b9e6bc982203d1 (patch) | |
| tree | 598f8b9fa431b228d29897e798de4ac0c1d3d970 /docs/programmer_reference/lock_notxn.html | |
| parent | 7a2660ba9cc2dc03a69ddfcfd95369395cc87444 (diff) | |
| download | berkeleydb-master.tar.gz | |
Diffstat (limited to 'docs/programmer_reference/lock_notxn.html')
| -rw-r--r-- | docs/programmer_reference/lock_notxn.html | 65 |
1 files changed, 36 insertions, 29 deletions
diff --git a/docs/programmer_reference/lock_notxn.html b/docs/programmer_reference/lock_notxn.html index 0455d4a1..8d1f7959 100644 --- a/docs/programmer_reference/lock_notxn.html +++ b/docs/programmer_reference/lock_notxn.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_page.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_twopl.html">Next</a></td> </tr> </table> @@ -38,30 +36,38 @@ </div> </div> </div> - <p>If an application runs with locking specified, but not transactions (for -example, <a href="../api_reference/C/envopen.html" class="olink">DB_ENV->open()</a> is callsed with <a href="../api_reference/C/envopen.html#envopen_DB_INIT_LOCK" class="olink">DB_INIT_LOCK</a> or -<a href="../api_reference/C/envopen.html#envopen_DB_INIT_CDB" class="olink">DB_INIT_CDB</a> specified, but not <a href="../api_reference/C/envopen.html#envopen_DB_INIT_TXN" class="olink">DB_INIT_TXN</a>), locks are -normally acquired during each Berkeley DB operation and released before the -operation returns to the caller. The only exception is in the case of -cursor operations. Cursors identify a particular position in a file. -For this reason, cursors must retain read locks across cursor calls to -make sure that the position is uniquely identifiable during a subsequent -cursor call, and so that an operation using <a href="../api_reference/C/dbcget.html#dbcget_DB_CURRENT" class="olink">DB_CURRENT</a> will -always refer to the same record as a previous cursor call. These cursor -locks cannot be released until the cursor is either repositioned and a -new cursor lock established (for example, using the <a href="../api_reference/C/dbcget.html#dbcget_DB_NEXT" class="olink">DB_NEXT</a> -or <a href="../api_reference/C/dbcget.html#dbcget_DB_SET" class="olink">DB_SET</a> flags), or the cursor is closed. As a result, -application writers are encouraged to close cursors as soon as -possible.</p> - <p>It is important to realize that concurrent applications that use locking -must ensure that two concurrent threads do not block each other. -However, because Btree and Hash access method page splits can occur at -any time, there is virtually no way to guarantee that an application -that writes the database cannot deadlock. Applications running without -the protection of transactions may deadlock, and can leave the database -in an inconsistent state when they do so. Applications that need -concurrent access, but not transactions, are more safely implemented -using the Berkeley DB Concurrent Data Store Product.</p> + <p> + If an application runs with locking specified, but not + transactions (for example, <a href="../api_reference/C/envopen.html" class="olink">DB_ENV->open()</a> is callsed with + <a href="../api_reference/C/envopen.html#envopen_DB_INIT_LOCK" class="olink">DB_INIT_LOCK</a> or <a href="../api_reference/C/envopen.html#envopen_DB_INIT_CDB" class="olink">DB_INIT_CDB</a> specified, but not + <a href="../api_reference/C/envopen.html#envopen_DB_INIT_TXN" class="olink">DB_INIT_TXN</a>), locks are normally acquired during each + Berkeley DB operation and released before the operation + returns to the caller. The only exception is in the case of + cursor operations. Cursors identify a particular position in a + file. For this reason, cursors must retain read locks across + cursor calls to make sure that the position is uniquely + identifiable during a subsequent cursor call, and so that an + operation using <a href="../api_reference/C/dbcget.html#dbcget_DB_CURRENT" class="olink">DB_CURRENT</a> will always refer to the same + record as a previous cursor call. These cursor locks cannot be + released until the cursor is either repositioned and a new + cursor lock established (for example, using the <a href="../api_reference/C/dbcget.html#dbcget_DB_NEXT" class="olink">DB_NEXT</a> or + <a href="../api_reference/C/dbcget.html#dbcget_DB_SET" class="olink">DB_SET</a> flags), or the cursor is closed. As a result, + application writers are encouraged to close cursors as soon as + possible. + </p> + <p> + It is important to realize that concurrent applications that + use locking must ensure that two concurrent threads do not + block each other. However, because Btree and Hash access + method page splits can occur at any time, there is virtually + no way to guarantee that an application that writes the + database cannot deadlock. Applications running without the + protection of transactions may deadlock, and can leave the + database in an inconsistent state when they do so. + Applications that need concurrent access, but not + transactions, are more safely implemented using the Berkeley + DB Concurrent Data Store Product. + </p> </div> <div class="navfooter"> <hr /> @@ -78,7 +84,8 @@ using the Berkeley DB Concurrent Data Store Product.</p> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> - <td width="40%" align="right" valign="top"> Locking with transactions: two-phase locking</td> + <td width="40%" align="right" valign="top"> Locking with transactions: two-phase + locking</td> </tr> </table> </div> |