← 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/notxn.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/notxn.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: Locking without transactions</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/page.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/twopl.html"><img src="../../images/next.gif" alt="Next"></a>
16
 
</td></tr></table>
17
 
<p>
18
 
<h1 align=center>Locking without transactions</h1>
19
 
<p>If an application runs with locking specified, but not transactions (for
20
 
example, <a href="../../api_c/env_open.html">DB_ENV-&gt;open</a> is called with <a href="../../api_c/env_open.html#DB_INIT_LOCK">DB_INIT_LOCK</a> or
21
 
<a href="../../api_c/env_open.html#DB_INIT_CDB">DB_INIT_CDB</a> specified, but not <a href="../../api_c/env_open.html#DB_INIT_TXN">DB_INIT_TXN</a>), locks are
22
 
normally acquired during each Berkeley DB operation and released before the
23
 
operation returns to the caller.  The only exception is in the case of
24
 
cursor operations.  Cursors identify a particular position in a file.
25
 
For this reason, cursors must retain read locks across cursor calls to
26
 
make sure that the position is uniquely identifiable during a subsequent
27
 
cursor call, and so that an operation using <a href="../../api_c/dbc_get.html#DB_CURRENT">DB_CURRENT</a> will
28
 
always refer to the same record as a previous cursor call.  These cursor
29
 
locks cannot be released until the cursor is either repositioned and a
30
 
new cursor lock established (for example, using the <a href="../../api_c/dbc_get.html#DB_NEXT">DB_NEXT</a>
31
 
or <a href="../../api_c/dbc_get.html#DB_SET">DB_SET</a> flags), or the cursor is closed.  As a result,
32
 
application writers are encouraged to close cursors as soon as
33
 
possible.
34
 
<p>It is important to realize that concurrent applications that use locking
35
 
must ensure that two concurrent threads do not block each other.
36
 
However, because Btree and Hash access method page splits can occur at
37
 
any time, there is virtually no way to guarantee that an application
38
 
that writes the database cannot deadlock.  Applications running without
39
 
the protection of transactions may deadlock, and can leave the database
40
 
in an inconsistent state when they do so.  Applications that need
41
 
concurrent access, but not transactions, are more safely implemented
42
 
using the Berkeley DB Concurrent Data Store Product.
43
 
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/lock/page.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/twopl.html"><img src="../../images/next.gif" alt="Next"></a>
44
 
</td></tr></table>
45
 
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
46
 
</body>
47
 
</html>