1<!--$Id: cam_conv.so,v 10.15 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: Berkeley DB Concurrent Data Store locking conventions</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/twopl.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/lock/am_conv.html"><img src="/images/next.gif" alt="Next"></a> 15</td></tr></table> 16<p align=center><b>Berkeley DB Concurrent Data Store locking conventions</b></p> 17<p>The Berkeley DB Concurrent Data Store product has a simple set of conventions for locking. It 18provides multiple-reader/single-writer semantics, but not per-page 19locking or transaction recoverability. As such, it does its locking 20entirely in the Berkeley DB interface layer.</p> 21<p>The object it locks is the file, identified by its unique file number. 22The locking matrix is not one of the two standard lock modes, instead, 23we use a four-lock set, consisting of the following:</p> 24<br> 25<b>DB_LOCK_NG</b><ul compact><li>not granted (always 0)</ul> 26<b>DB_LOCK_READ</b><ul compact><li>read (shared)</ul> 27<b>DB_LOCK_WRITE</b><ul compact><li>write (exclusive)</ul> 28<b>DB_LOCK_IWRITE</b><ul compact><li>intention-to-write (shared with NG and READ, but conflicts with WRITE and IWRITE)</ul> 29<br> 30<p>The IWRITE lock is used for cursors that will be used for updating 31(IWRITE locks are implicitly obtained for write operations through the 32Berkeley DB handles, for example, <a href="/api_c/db_put.html">DB->put</a> or <a href="/api_c/db_del.html">DB->del</a>). While 33the cursor is reading, the IWRITE lock is held; but as soon as the 34cursor is about to modify the database, the IWRITE is upgraded to a 35WRITE lock. This upgrade blocks until all readers have exited the 36database. Because only one IWRITE lock is allowed at any one time, no 37two cursors can ever try to upgrade to a WRITE lock at the same time, 38and therefore deadlocks are prevented, which is essential because Berkeley DB Concurrent Data Store 39does not include deadlock detection and recovery.</p> 40<p>Applications that need to lock compatibly with Berkeley DB Concurrent Data Store must obey the 41following rules:</p> 42<ol> 43<p><li>Use only lock modes DB_LOCK_NG, DB_LOCK_READ, DB_LOCK_WRITE, 44DB_LOCK_IWRITE. 45<p><li>Never attempt to acquire a WRITE lock on an object that is 46already locked with a READ lock. 47</ol> 48<table width="100%"><tr><td><br></td><td align=right><a href="/lock/twopl.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/lock/am_conv.html"><img src="/images/next.gif" alt="Next"></a> 49</td></tr></table> 50<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 51</body> 52</html> 53