1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
<!--$Id: read.so,v 1.8 2004/01/12 05:33:23 ubell Exp $-->
<!--Copyright 1997-2004 by Sleepycat Software, Inc.-->
<!--All rights reserved.-->
<!--See the file LICENSE for redistribution information.-->
<html>
<head>
<title>Berkeley DB Reference Guide: Degrees of isolation</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++">
</head>
<body bgcolor=white>
<table width="100%"><tr valign=top>
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Transactional Data Store Applications</dl></h3></td>
<td align=right><a href="../transapp/inc.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../transapp/cursor.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
<p>
<h3 align=center>Degrees of isolation</h3>
<a name="2"><!--meow--></a>
<p>Transactions can be isolated from each other to different degrees.
<i>Repeatable reads</i> provide the most isolation, and mean that,
for the life of the transaction, every time a thread of control reads
a data item, it will be unchanged from its previous value (assuming, of
course, the thread of control does not itself modify the item). Berkeley DB
enforces repeatable reads whenever database reads are wrapped in
transactions. This is also know as <i>degree 3 isolation</i>.</p>
<p>Most applications do not need to enclose reads in transactions, and when
possible, transactionally protected reads should be avoided as they can
cause performance problems. For example, a transactionally protected
cursor sequentially reading each key/data pair in a database, will
acquire a read lock on most of the pages in the database and so will
gradually block all write operations on the databases until the
transaction commits or aborts. Note, however, that if there are update
transactions present in the application, the read operations must still
use locking, and must be prepared to repeat any operation (possibly
closing and reopening a cursor) that fails with a return value of
<a href="../../ref/program/errorret.html#DB_LOCK_DEADLOCK">DB_LOCK_DEADLOCK</a>. Applications that need repeatable reads are
ones that require the ability to repeatedly access a data item knowing
that it will not have changed (for example, an operation modifying a
data item based on its existing value).</p>
<a name="3"><!--meow--></a>
<a name="4"><!--meow--></a>
<a name="5"><!--meow--></a>
<a name="6"><!--meow--></a>
<p>A transaction may only require <i>cursor stability</i>, that is
only be guaranteed that cursors see committed data that does
not change so long as it is addressed by the cursor, but may
change before the reading transaction completes. This is
also called <i>degree 2 isolation</i>. Berkeley DB provides
this level of isolation when a transaction is started with
the <a href="../../api_c/db_cursor.html#DB_DEGREE_2">DB_DEGREE_2</a> flag. This flag may also be specified
when opening a cursor within a fully isolated transaction.</p>
<a name="7"><!--meow--></a>
<a name="8"><!--meow--></a>
<p>Berkeley DB optionally supports reading uncommitted data; that is, read
operations may request data which has been modified but not yet
committed by another transaction. This is done by first specifying the
<a href="../../api_c/db_open.html#DB_DIRTY_READ">DB_DIRTY_READ</a> flag when opening the underlying database, and
then specifying the <a href="../../api_c/db_open.html#DB_DIRTY_READ">DB_DIRTY_READ</a> flag when beginning a
transaction, opening a cursor, or performing a read operation. The
advantage of using <a href="../../api_c/db_open.html#DB_DIRTY_READ">DB_DIRTY_READ</a> is that read operations will
not block when another transaction holds a write lock on the requested
data; the disadvantage is that read operations may return data that will
disappear should the transaction holding the write lock abort.</p>
<table width="100%"><tr><td><br></td><td align=right><a href="../transapp/inc.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../transapp/cursor.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
<p><font size=1><a href="../../sleepycat/legal.html">Copyright (c) 1996-2004</a> <a href="http://www.sleepycat.com">Sleepycat Software, Inc.</a> - All rights reserved.</font>
</body>
</html>
|
