← Back to branch summary

~ubuntu-branches/ubuntu/edgy/rpm/edgy

« back to all changes in this revision

Viewing changes to db/docs/ref/transapp/nested.html

  • Committer: Bazaar Package Importer
  • Author(s): Joey Hess
  • Date: 2002-01-22 20:56:57 UTC
  • Revision ID: james.westby@ubuntu.com-20020122205657-l74j50mr9z8ofcl5
Tags: upstream-4.0.3
Import upstream version 4.0.3

Show diffs side-by-side

added added

removed removed

Lines of Context:
db/docs/ref/transapp/nested.html
 
1
<!--$Id: nested.so,v 10.22 2001/03/02 21:01:22 bostic Exp $-->
 
2
<!--Copyright 1997-2001 by Sleepycat Software, Inc.-->
 
3
<!--All rights reserved.-->
 
4
<html>
 
5
<head>
 
6
<title>Berkeley DB Reference Guide: Nested transactions</title>
 
7
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
 
8
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,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><h3><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Transactional Data Store Applications</dl></h3></td>
 
14
<td align=right><a href="../../ref/transapp/cursor.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/transapp/admin.html"><img src="../../images/next.gif" alt="Next"></a>
 
15
</td></tr></table>
 
16
<p>
 
17
<h1 align=center>Nested transactions</h1>
 
18
<p>Berkeley DB provides support for nested transactions.  Nested transactions
 
19
allow an application to decompose a large or long-running transaction
 
20
into smaller units that may be independently aborted.
 
21
<p>Normally, when beginning a transaction, the application will pass a NULL
 
22
value for the parent argument to <a href="../../api_c/txn_begin.html">txn_begin</a>.  If, however, the
 
23
parent argument is a DB_TXN handle, the newly created transaction
 
24
will be treated as a nested transaction within the parent.  Transactions
 
25
may nest arbitrarily deeply.  For the purposes of this discussion,
 
26
transactions created with a parent identifier will be called
 
27
<i>child transactions</i>.
 
28
<p>Once a transaction becomes a parent, as long as any of its child
 
29
transactions are unresolved (that is, they have neither committed nor
 
30
aborted), the parent may not issue any Berkeley DB calls except to begin more
 
31
child transactions, or to commit or abort.  For example, it may not
 
32
issue any access method or cursor calls.  After all of a parent's
 
33
children have committed or aborted, the parent may again request
 
34
operations on its own behalf.
 
35
<p>The semantics of nested transactions are as follows.  When a child
 
36
transaction is begun, it inherits all the locks of its parent.  This
 
37
means that the child will never block waiting on a lock held by its
 
38
parent.  Further, locks held by two children of the same parent will
 
39
also conflict.  To make this concrete, consider the following set of
 
40
transactions and lock acquisitions.
 
41
<p>Transaction T1 is the parent transaction.  It acquires a write lock on
 
42
item A and then begins two child transactions: C1 and C2.  C1 also
 
43
wishes to acquire a write lock on A; this succeeds.  If C2 attempts to
 
44
acquire a write lock on A, it will block until C1 releases the lock, at
 
45
which point it will succeed.  Now, let's say that C1 acquires a write
 
46
lock on B.  If C2 now attempts to obtain a lock on B, it will block.
 
47
However, let's now assume that C1 commits.  Its locks are
 
48
anti-inherited, which means they are given to T1, so T1 will now hold
 
49
a lock on B.  At this point, C2 would be unblocked and would then
 
50
acquire a lock on B.
 
51
<p>Child transactions are entirely subservient to their parent transaction.
 
52
They may abort, undoing their operations regardless of the eventual fate
 
53
of the parent.  However, even if a child transaction commits, if its
 
54
parent transaction is eventually aborted, the child's changes are undone
 
55
and the child's transaction is effectively aborted.  Any child
 
56
transactions that are not yet resolved when the parent commits or aborts
 
57
are resolved based on the parent's resolution -- committing if the
 
58
parent commits and aborting if the parent aborts.  Any child
 
59
transactions that are not yet resolved when the parent prepares are also
 
60
prepared.
 
61
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/transapp/cursor.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/transapp/admin.html"><img src="../../images/next.gif" alt="Next"></a>
 
62
</td></tr></table>
 
63
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
 
64
</body>
 
65
</html>