1<!--$Id: nondb.so,v 10.15 2001/05/22 19:39:31 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 and non-Berkeley DB applications</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/am_conv.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../log/intro.html"><img src="../../images/next.gif" alt="Next"></a> 15</td></tr></table> 16<p align=center><b>Locking and non-Berkeley DB applications</b></p> 17<p>The Lock subsystem is useful outside the context of Berkeley DB. It can be 18used to manage concurrent access to any collection of either ephemeral 19or persistent objects. That is, the lock region can persist across 20invocations of an application, so it can be used to provide long-term 21locking (for example, conference room scheduling).</p> 22<p>In order to use the locking subsystem in such a general way, the 23applications must adhere to a convention for identifying objects and 24lockers. Consider a conference room scheduling problem, in which there 25are three conference rooms scheduled in half-hour intervals. The 26scheduling application must then select a way to identify each 27conference room/time slot combination. In this case, we could describe 28the objects being locked as bytestrings consisting of the conference 29room name, the date when it is needed, and the beginning of the 30appropriate half-hour slot.</p> 31<p>Lockers are 32-bit numbers, so we might choose to use the User ID of 32the individual running the scheduling program. To schedule half-hour 33slots, all the application needs to do is issue a <a href="../../api_c/lock_get.html">DB_ENV->lock_get</a> call 34for the appropriate locker/object pair. To schedule a longer slot, the 35application needs to issue a <a href="../../api_c/lock_vec.html">DB_ENV->lock_vec</a> call, with one 36<a href="../../api_c/lock_get.html">DB_ENV->lock_get</a> operation per half-hour -- up to the total length. If 37the <a href="../../api_c/lock_vec.html">DB_ENV->lock_vec</a> call fails, the application would have to release 38the parts of the time slot that were obtained.</p> 39<p>To cancel a reservation, the application would make the appropriate 40<a href="../../api_c/lock_put.html">DB_ENV->lock_put</a> calls. To reschedule a reservation, the 41<a href="../../api_c/lock_get.html">DB_ENV->lock_get</a> and <a href="../../api_c/lock_put.html">DB_ENV->lock_put</a> calls could all be made inside of 42a single <a href="../../api_c/lock_vec.html">DB_ENV->lock_vec</a> call. The output of <a href="../../api_c/lock_stat.html">DB_ENV->lock_stat</a> could 43be post-processed into a human-readable schedule of conference room 44use.</p> 45<table width="100%"><tr><td><br></td><td align=right><a href="../lock/am_conv.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../log/intro.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
