← 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/am_misc/stability.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/am_misc/stability.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: Cursor stability</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><a name="3"><!--meow--></a>
13
 
<table width="100%"><tr valign=top>
14
 
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Access Methods</dl></h3></td>
15
 
<td align=right><a href="../../ref/am_misc/error.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/am_misc/dbsizes.html"><img src="../../images/next.gif" alt="Next"></a>
16
 
</td></tr></table>
17
 
<p>
18
 
<h1 align=center>Cursor stability</h1>
19
 
<p>In the absence of locking, no guarantees are made about the stability
20
 
of cursors in different threads of control.  However, the Btree, Queue
21
 
and Recno access methods guarantee that cursor operations, interspersed
22
 
with any other operation in the same thread of control will always
23
 
return keys in order and will return each non-deleted key/data pair
24
 
exactly once.  Because the Hash access method uses a dynamic hashing
25
 
algorithm, it cannot guarantee any form of stability in the presence of
26
 
inserts and deletes unless transactional locking is performed.
27
 
<p>If locking was specified when the Berkeley DB environment was opened, but
28
 
transactions are not in effect, the access methods provide repeatable
29
 
reads with respect to the cursor.  That is, a <a href="../../api_c/dbc_get.html#DB_CURRENT">DB_CURRENT</a> call
30
 
on the cursor is guaranteed to return the same record as was returned
31
 
on the last call to the cursor.
32
 
<a name="4"><!--meow--></a><a name="5"><!--meow--></a>
33
 
<p>In the presence of transactions, the Btree, Hash and Recno access
34
 
methods provide degree 3 isolation (serializable transactions).  The
35
 
Queue access method provides degree 3 isolation with the exception that
36
 
it permits phantom records to appear between calls.  That is, deleted
37
 
records are not locked, therefore another transaction may replace a
38
 
deleted record between two calls to retrieve it.  The record would not
39
 
appear in the first call but would be seen by the second call.  For
40
 
readers not enclosed in transactions, all access method calls provide
41
 
degree 2 isolation, that is, reads are not repeatable.  Finally, Berkeley DB
42
 
provides degree 1 isolation when the <a href="../../api_c/db_open.html#DB_DIRTY_READ">DB_DIRTY_READ</a> flag is
43
 
specified; that is, reads may see data modified in transactions which
44
 
have not yet committed.
45
 
<p>For all access methods, a cursor scan of the database performed within
46
 
the context of a transaction is guaranteed to return each key/data pair
47
 
once and only once, except in the following case.  If, while performing
48
 
a cursor scan using the Hash access method, the transaction performing
49
 
the scan inserts a new pair into the database, it is possible that
50
 
duplicate key/data pairs will be returned.
51
 
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/am_misc/error.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/am_misc/dbsizes.html"><img src="../../images/next.gif" alt="Next"></a>
52
 
</td></tr></table>
53
 
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
54
 
</body>
55
 
</html>