← 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/xa/intro.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/xa/intro.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: Introduction</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>Distributed Transactions</dl></h3></td>
15
 
<td align=right><a href="../../ref/rep/ex_rq.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/xa/build.html"><img src="../../images/next.gif" alt="Next"></a>
16
 
</td></tr></table>
17
 
<p>
18
 
<h1 align=center>Introduction</h1>
19
 
<p>Berkeley DB provides support for distributed transactions using a two-phase
20
 
commit protocol via its <a href="../../api_c/txn_prepare.html">DB_TXN-&gt;prepare</a> and <a href="../../api_c/txn_recover.html">DB_ENV-&gt;txn_recover</a>
21
 
interfaces.  The <a href="../../api_c/txn_prepare.html">DB_TXN-&gt;prepare</a> method performs the first phase of a
22
 
two-phase commit, flushing the log to disk, and associating a global
23
 
transaction ID with the underlying Berkeley DB transaction.  This global
24
 
transaction ID should be used by the global transaction manager to
25
 
identify the Berkeley DB transaction, and will be returned by the
26
 
<a href="../../api_c/txn_recover.html">DB_ENV-&gt;txn_recover</a> method when it is called during recovery.
27
 
<p>Distributed transactions are necessary whenever an application wants to
28
 
transaction-protect data in multiple Berkeley DB environments, even if those
29
 
environments are on the same machine.  However, Berkeley DB does not perform
30
 
distributed deadlock detection, therefore it is the responsibility of
31
 
the application to ensure that accesses in different environments cannot
32
 
deadlock (this can be accomplished through careful ordering of
33
 
operations to the multiple environments), or by using the
34
 
<a href="../../api_c/lock_vec.html#DB_LOCK_NOWAIT">DB_LOCK_NOWAIT</a> option and eventually abort transactions that
35
 
have been waiting "too long" (where "too long" is determined by an
36
 
application-specific timeout).
37
 
<p>In order to use the two-phase commit feature of Berkeley DB, an application
38
 
must either implement its own global transaction manager or use an
39
 
XA-compliant transaction manager (as Berkeley DB can act as an XA-compliant
40
 
resource manager).
41
 
<p>When using distributed transactions, there is no way to perform
42
 
hot backups of multiple environments and guarantee that the backups
43
 
are global-transaction-consistent across these multiple environments.
44
 
If backups are desired, then all write transactions should be suspended;
45
 
that is, active write transactions must be allowed to complete and no
46
 
new write transactions should be begun.  Once there are no active write
47
 
transactions, the logs may be copied for backup purposes and the backup
48
 
will be consistent across the multiple environments.
49
 
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/rep/ex_rq.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/xa/build.html"><img src="../../images/next.gif" alt="Next"></a>
50
 
</td></tr></table>
51
 
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
52
 
</body>
53
 
</html>