diff options
Diffstat (limited to 'docs/programmer_reference/lock_twopl.html')
| -rw-r--r-- | docs/programmer_reference/lock_twopl.html | 82 |
1 files changed, 50 insertions, 32 deletions
diff --git a/docs/programmer_reference/lock_twopl.html b/docs/programmer_reference/lock_twopl.html index 044c68d1..067bd4dd 100644 --- a/docs/programmer_reference/lock_twopl.html +++ b/docs/programmer_reference/lock_twopl.html @@ -14,17 +14,16 @@ <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> - <th colspan="3" align="center">Locking with transactions: two-phase locking</th> + <th colspan="3" align="center">Locking with transactions: two-phase + locking</th> </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="lock_notxn.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_cam_conv.html">Next</a></td> </tr> </table> @@ -34,38 +33,57 @@ <div class="titlepage"> <div> <div> - <h2 class="title" style="clear: both"><a id="lock_twopl"></a>Locking with transactions: two-phase locking</h2> + <h2 class="title" style="clear: both"><a id="lock_twopl"></a>Locking with transactions: two-phase + locking</h2> </div> </div> </div> - <p>Berkeley DB uses a locking protocol called <span class="emphasis"><em>two-phase locking (2PL)</em></span>. This -is the traditional protocol used in conjunction with lock-based transaction -systems.</p> - <p>In a two-phase locking system, transactions are divided into two -distinct phases. During the first phase, the transaction only acquires -locks; during the second phase, the transaction only releases locks. -More formally, once a transaction releases a lock, it may not acquire -any additional locks. Practically, this translates into a system in -which locks are acquired as they are needed throughout a transaction -and retained until the transaction ends, either by committing or -aborting. In Berkeley DB, locks are released during <a href="../api_reference/C/txnabort.html" class="olink">DB_TXN->abort()</a> or -<a href="../api_reference/C/txncommit.html" class="olink">DB_TXN->commit()</a>. The only exception to this protocol occurs when we -use lock-coupling to traverse a data structure. If the locks are held -only for traversal purposes, it is safe to release locks before -transactions commit or abort.</p> - <p>For applications, the implications of 2PL are that long-running -transactions will hold locks for a long time. When designing -applications, lock contention should be considered. In order to reduce -the probability of deadlock and achieve the best level of concurrency -possible, the following guidelines are helpful.</p> + <p> + Berkeley DB uses a locking protocol called + <span class="emphasis"><em>two-phase locking (2PL)</em></span>. This is the + traditional protocol used in conjunction with lock-based + transaction systems. + </p> + <p> + In a two-phase locking system, transactions are divided into + two distinct phases. During the first phase, the transaction + only acquires locks; during the second phase, the transaction + only releases locks. More formally, once a transaction + releases a lock, it may not acquire any additional locks. + Practically, this translates into a system in which locks are + acquired as they are needed throughout a transaction and + retained until the transaction ends, either by committing or + aborting. In Berkeley DB, locks are released during <a href="../api_reference/C/txnabort.html" class="olink">DB_TXN->abort()</a> + or <a href="../api_reference/C/txncommit.html" class="olink">DB_TXN->commit()</a>. The only exception to this protocol occurs + when we use lock-coupling to traverse a data structure. If the + locks are held only for traversal purposes, it is safe to + release locks before transactions commit or abort. + </p> + <p> + For applications, the implications of 2PL are that + long-running transactions will hold locks for a long time. + When designing applications, lock contention should be + considered. In order to reduce the probability of deadlock and + achieve the best level of concurrency possible, the following + guidelines are helpful. + </p> <div class="orderedlist"> <ol type="1"> - <li>When accessing multiple databases, design all transactions so that they -access the files in the same order.</li> - <li>If possible, access your most hotly contested resources last (so that -their locks are held for the shortest time possible).</li> - <li>If possible, use nested transactions to protect the parts of your -transaction most likely to deadlock.</li> + <li> + When accessing multiple databases, design all + transactions so that they access the files in the same + order. + </li> + <li> + If possible, access your most hotly contested + resources last (so that their locks are held for the + shortest time possible). + </li> + <li> + If possible, use nested transactions to protect the + parts of your transaction most likely to + deadlock. + </li> </ol> </div> </div> |