1<!--$Id: twopl.so,v 10.11 2001/05/22 19:39:32 bostic Exp $-->
2<!--Copyright (c) 1997,2008 Oracle.  All rights reserved.-->
3<!--See the file LICENSE for redistribution information.-->
4<html>
5<head>
6<title>Berkeley DB Reference Guide: Locking with transactions: two-phase locking</title>
7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++">
9</head>
10<body bgcolor=white>
11<a name="2"><!--meow--></a>
12<table width="100%"><tr valign=top>
13<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Locking Subsystem</dl></b></td>
14<td align=right><a href="../lock/notxn.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../lock/cam_conv.html"><img src="../../images/next.gif" alt="Next"></a>
15</td></tr></table>
16<p align=center><b>Locking with transactions: two-phase locking</b></p>
17<p>Berkeley DB uses a locking protocol called <i>two-phase locking (2PL)</i>.  This
18is the traditional protocol used in conjunction with lock-based transaction
19systems.</p>
20<p>In a two-phase locking system, transactions are divided into two
21distinct phases.  During the first phase, the transaction only acquires
22locks; during the second phase, the transaction only releases locks.
23More formally, once a transaction releases a lock, it may not acquire
24any additional locks.  Practically, this translates into a system in
25which locks are acquired as they are needed throughout a transaction
26and retained until the transaction ends, either by committing or
27aborting.  In Berkeley DB, locks are released during <a href="../../api_c/txn_abort.html">DB_TXN-&gt;abort</a> or
28<a href="../../api_c/txn_commit.html">DB_TXN-&gt;commit</a>.  The only exception to this protocol occurs when we
29use lock-coupling to traverse a data structure.  If the locks are held
30only for traversal purposes, it is safe to release locks before
31transactions commit or abort.</p>
32<p>For applications, the implications of 2PL are that long-running
33transactions will hold locks for a long time.  When designing
34applications, lock contention should be considered.  In order to reduce
35the probability of deadlock and achieve the best level of concurrency
36possible, the following guidelines are helpful.</p>
37<ol>
38<p><li>When accessing multiple databases, design all transactions so that they
39access the files in the same order.
40<p><li>If possible, access your most hotly contested resources last (so that
41their locks are held for the shortest time possible).
42<p><li>If possible, use nested transactions to protect the parts of your
43transaction most likely to deadlock.
44</ol>
45<table width="100%"><tr><td><br></td><td align=right><a href="../lock/notxn.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../lock/cam_conv.html"><img src="../../images/next.gif" alt="Next"></a>
46</td></tr></table>
47<p><font size=1>Copyright (c) 1996,2008 Oracle.  All rights reserved.</font>
48</body>
49</html>
50