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