← Back to branch summary

~ubuntu-branches/ubuntu/maverick/evolution-data-server/maverick-proposed

« back to all changes in this revision

Viewing changes to libdb/docs/ref/lock/stdmode.html

  • Committer: Bazaar Package Importer
  • Author(s): Didier Roche
  • Date: 2010-05-17 17:02:06 UTC
  • mfrom: (1.1.79 upstream) (1.6.12 experimental)
  • Revision ID: james.westby@ubuntu.com-20100517170206-4ufr52vwrhh26yh0
Tags: 2.30.1-1ubuntu1
https://launchpad.net/bugs/42199
https://launchpad.net/bugs/229669
https://launchpad.net/bugs/173703
https://launchpad.net/bugs/360344
https://launchpad.net/bugs/508494
* Merge from debian experimental. Remaining change:
  (LP: #42199, #229669, #173703, #360344, #508494)
  + debian/control:
    - add Vcs-Bzr tag
    - don't use libgnome
    - Use Breaks instead of Conflicts against evolution 2.25 and earlier.
  + debian/evolution-data-server.install,
    debian/patches/45_libcamel_providers_version.patch:
    - use the upstream versioning, not a Debian-specific one 
  + debian/libedata-book1.2-dev.install, debian/libebackend-1.2-dev.install,
    debian/libcamel1.2-dev.install, debian/libedataserverui1.2-dev.install:
    - install html documentation
  + debian/rules:
    - don't build documentation it's shipped with the tarball

Show diffs side-by-side

added added

removed removed

Lines of Context:
libdb/docs/ref/lock/stdmode.html
1
 
<!--$Id$-->
2
 
<!--Copyright 1997-2002 by Sleepycat Software, Inc.-->
3
 
<!--All rights reserved.-->
4
 
<!--See the file LICENSE for redistribution information.-->
5
 
<html>
6
 
<head>
7
 
<title>Berkeley DB Reference Guide: Standard lock modes</title>
8
 
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
9
 
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++">
10
 
</head>
11
 
<body bgcolor=white>
12
 
<a name="2"><!--meow--></a>
13
 
<table width="100%"><tr valign=top>
14
 
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Locking Subsystem</dl></h3></td>
15
 
<td align=right><a href="../../ref/lock/max.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/lock/dead.html"><img src="../../images/next.gif" alt="Next"></a>
16
 
</td></tr></table>
17
 
<p>
18
 
<h1 align=center>Standard lock modes</h1>
19
 
<p>The Berkeley DB locking protocol is described by a conflict matrix.  A
20
 
conflict matrix is an NxN array in which N is the number of different
21
 
lock modes supported, and the (i, j)th entry of the array indicates
22
 
whether a lock of mode i conflicts with a lock of mode j.  In addition,
23
 
Berkeley DB defines the type <b>db_lockmode_t</b>, which is the type of a
24
 
lock mode within a conflict matrix.
25
 
<p>The following is an example of a conflict matrix.  The actual conflict
26
 
matrix used by Berkeley DB to support the underlying access methods is more
27
 
complicated, but this matrix shows the lock mode relationships available
28
 
to applications using the Berkeley DB Locking subsystem interfaces directly.
29
 
<p><dl compact>
30
 
<p><dt>DB_LOCK_NG<dd>not granted (always 0)
31
 
<dt>DB_LOCK_READ<dd>read (shared)
32
 
<dt>DB_LOCK_WRITE<dd>write (exclusive)
33
 
<dt>DB_LOCK_IWRITE<dd>intention to write (shared)
34
 
<dt>DB_LOCK_IREAD<dd>intention to read (shared)
35
 
<dt>DB_LOCK_IWR<dd>intention to read and write (shared)
36
 
</dl>
37
 
<p>In a conflict matrix, the rows indicate the lock that is held, and the
38
 
columns indicate the lock that is requested.  A 1 represents a conflict
39
 
(that is, do not grant the lock if the indicated lock is held), and a
40
 
0 indicates that it is OK to grant the lock.
41
 
<p><blockquote><pre>            Notheld Read    Write   IWrite  IRead   IRW
42
 
Notheld         0       0       0       0       0       0
43
 
Read*           0       0       1       1       0       1
44
 
Write**         0       1       1       1       1       1
45
 
Intent Write    0       1       1       0       0       0
46
 
Intent Read     0       0       1       0       0       0
47
 
Intent RW       0       1       1       0       0       0</pre></blockquote>
48
 
<p><dl compact>
49
 
<p><dt>*<dd>In this case, suppose that there is a read lock held on an object.  A new
50
 
request for a read lock would be granted, but a request for a write lock
51
 
would not.
52
 
<p><dt>**<dd>In this case, suppose that there is a write lock held on an object.  A
53
 
new request for either a read or write lock would be denied.
54
 
</dl>
55
 
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/lock/max.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/lock/dead.html"><img src="../../images/next.gif" alt="Next"></a>
56
 
</td></tr></table>
57
 
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
58
 
</body>
59
 
</html>