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_page.html | |
| parent | 7a2660ba9cc2dc03a69ddfcfd95369395cc87444 (diff) | |
| download | berkeleydb-master.tar.gz | |
Diffstat (limited to 'docs/programmer_reference/lock_page.html')
| -rw-r--r-- | docs/programmer_reference/lock_page.html | 131 |
1 files changed, 80 insertions, 51 deletions
diff --git a/docs/programmer_reference/lock_page.html b/docs/programmer_reference/lock_page.html index b1733b70..06c099de 100644 --- a/docs/programmer_reference/lock_page.html +++ b/docs/programmer_reference/lock_page.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_deaddbg.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_notxn.html">Next</a></td> </tr> </table> @@ -38,57 +36,88 @@ </div> </div> </div> - <p>With the exception of the Queue access method, the Berkeley DB access methods -do page-level locking. The size of pages in a database may be set when -the database is created by calling the <a href="../api_reference/C/dbset_pagesize.html" class="olink">DB->set_pagesize()</a> method. If -not specified by the application, Berkeley DB selects a page size that will -provide the best I/O performance by setting the page size equal to the -block size of the underlying file system. Selecting a smaller page size -can result in increased concurrency for some applications.</p> - <p>In the Btree access method, Berkeley DB uses a technique called lock coupling -to improve concurrency. The traversal of a Btree requires reading a -page, searching that page to determine which page to search next, and -then repeating this process on the next page. Once a page has been -searched, it will never be accessed again for this operation, unless a -page split is required. To improve concurrency in the tree, once the -next page to read/search has been determined, that page is locked and -then the original page lock is released atomically (that is, without -relinquishing control of the lock manager). When page splits become -necessary, write locks are reacquired.</p> - <p>Because the Recno access method is built upon Btree, it also uses lock -coupling for read operations. However, because the Recno access method -must maintain a count of records on its internal pages, it cannot -lock-couple during write operations. Instead, it retains write locks -on all internal pages during every update operation. For this reason, -it is not possible to have high concurrency in the Recno access method -in the presence of write operations.</p> - <p>The Queue access method uses only short-term page locks. That is, a page -lock is released prior to requesting another page lock. Record locks are -used for transaction isolation. The provides a high degree of concurrency -for write operations. A metadata page is used to keep track of the head -and tail of the queue. This page is never locked during other locking or -I/O operations.</p> - <p>The Hash access method does not have such traversal issues, but it must -always refer to its metadata while computing a hash function because it -implements dynamic hashing. This metadata is stored on a special page -in the hash database. This page must therefore be read-locked on every -operation. Fortunately, it needs to be write-locked only when new pages -are allocated to the file, which happens in three cases:</p> + <p> + With the exception of the Queue access method, the Berkeley + DB access methods do page-level locking. The size of pages in + a database may be set when the database is created by calling + the <a href="../api_reference/C/dbset_pagesize.html" class="olink">DB->set_pagesize()</a> method. If not specified by the + application, Berkeley DB selects a page size that will provide + the best I/O performance by setting the page size equal to the + block size of the underlying file system. Selecting a smaller + page size can result in increased concurrency for some + applications. + </p> + <p> + In the Btree access method, Berkeley DB uses a technique + called lock coupling to improve concurrency. The traversal of + a Btree requires reading a page, searching that page to + determine which page to search next, and then repeating this + process on the next page. Once a page has been searched, it + will never be accessed again for this operation, unless a page + split is required. To improve concurrency in the tree, once + the next page to read/search has been determined, that page is + locked and then the original page lock is released atomically + (that is, without relinquishing control of the lock manager). + When page splits become necessary, write locks are + reacquired. + </p> + <p> + Because the Recno access method is built upon Btree, it also + uses lock coupling for read operations. However, because the + Recno access method must maintain a count of records on its + internal pages, it cannot lock-couple during write operations. + Instead, it retains write locks on all internal pages during + every update operation. For this reason, it is not possible to + have high concurrency in the Recno access method in the + presence of write operations. + </p> + <p> + The Queue access method uses only short-term page locks. + That is, a page lock is released prior to requesting another + page lock. Record locks are used for transaction isolation. + The provides a high degree of concurrency for write + operations. A metadata page is used to keep track of the head + and tail of the queue. This page is never locked during other + locking or I/O operations. + </p> + <p> + The Hash access method does not have such traversal issues, + but it must always refer to its metadata while computing a + hash function because it implements dynamic hashing. This + metadata is stored on a special page in the hash database. + This page must therefore be read-locked on every operation. + Fortunately, it needs to be write-locked only when new pages + are allocated to the file, which happens in three + cases: + </p> <div class="itemizedlist"> <ul type="disc"> - <li>a hash bucket becomes full and needs to split</li> - <li>a key or data item is too large to fit on a normal page</li> - <li>the number of duplicate items for a fixed key becomes so large that they -are moved to an auxiliary page</li> + <li> + a hash bucket becomes full and needs to + split + </li> + <li> + a key or data item is too large to fit on a normal + page + </li> + <li> + the number of duplicate items for a fixed key + becomes so large that they are moved to an auxiliary + page + </li> </ul> </div> - <p>In this case, the access method must obtain a write lock on the metadata -page, thus requiring that all readers be blocked from entering the tree -until the update completes.</p> - <p>Finally, when traversing duplicate data items for a key, the lock on -the key value also acts as a lock on all duplicates of that key. -Therefore, two conflicting threads of control cannot access the same -duplicate set simultaneously.</p> + <p> + In this case, the access method must obtain a write lock on + the metadata page, thus requiring that all readers be blocked + from entering the tree until the update completes. + </p> + <p> + Finally, when traversing duplicate data items for a key, the + lock on the key value also acts as a lock on all duplicates of + that key. Therefore, two conflicting threads of control cannot + access the same duplicate set simultaneously. + </p> </div> <div class="navfooter"> <hr /> |