1<!--$Id: stdmode.so,v 10.27 2007/10/26 15:02:17 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: Standard lock modes</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/max.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../lock/dead.html"><img src="../../images/next.gif" alt="Next"></a>
15</td></tr></table>
16<p align=center><b>Standard lock modes</b></p>
17<p>The Berkeley DB locking protocol is described by a conflict matrix.  A
18conflict matrix is an NxN array in which N is the number of different
19lock modes supported, and the (i, j)th entry of the array indicates
20whether a lock of mode i conflicts with a lock of mode j.  In addition,
21Berkeley DB defines the type <b>db_lockmode_t</b>, which is the type of a
22lock mode within a conflict matrix.</p>
23<p>The following is an example of a conflict matrix.  The actual conflict
24matrix used by Berkeley DB to support the underlying access methods is more
25complicated, but this matrix shows the lock mode relationships available
26to applications using the Berkeley DB Locking subsystem interfaces directly.</p>
27<br>
28<b>DB_LOCK_NG</b><ul compact><li>not granted (always 0)</ul>
29<b>DB_LOCK_READ</b><ul compact><li>read (shared)</ul>
30<b>DB_LOCK_WRITE</b><ul compact><li>write (exclusive)</ul>
31<b>DB_LOCK_IWRITE</b><ul compact><li>intention to write (shared)</ul>
32<b>DB_LOCK_IREAD</b><ul compact><li>intention to read (shared)</ul>
33<b>DB_LOCK_IWR</b><ul compact><li>intention to read and write (shared)</ul>
34<br>
35<p>In a conflict matrix, the rows indicate the lock that is held, and the
36columns indicate the lock that is requested.  A 1 represents a conflict
37(that is, do not grant the lock if the indicated lock is held), and a
380 indicates that it is OK to grant the lock.</p>
39<blockquote><pre>		Notheld	Read    Write	IWrite	IRead	IRW
40Notheld		0	0	0	0	0	0
41Read*		0	0	1	1	0	1
42Write**		0	1	1	1	1	1
43Intent Write	0	1	1	0	0	0
44Intent Read	0	0	1	0	0	0
45Intent RW	0	1	1	0	0	0</pre></blockquote>
46<br>
47<b>*</b><ul compact><li>In this case, suppose that there is a read lock held on an object.  A new
48request for a read lock would be granted, but a request for a write lock
49would not.</ul>
50<b>**</b><ul compact><li>In this case, suppose that there is a write lock held on an object.  A
51new request for either a read or write lock would be denied.</ul>
52<br>
53<table width="100%"><tr><td><br></td><td align=right><a href="../lock/max.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../lock/dead.html"><img src="../../images/next.gif" alt="Next"></a>
54</td></tr></table>
55<p><font size=1>Copyright (c) 1996,2008 Oracle.  All rights reserved.</font>
56</body>
57</html>
58