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