← 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/rep/trans.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/rep/trans.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: Transactional guarantees</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
 
<table width="100%"><tr valign=top>
13
 
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Replication</dl></h3></td>
14
 
<td align=right><a href="../../ref/rep/logonly.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/rep/partition.html"><img src="../../images/next.gif" alt="Next"></a>
15
 
</td></tr></table>
16
 
<p>
17
 
<h1 align=center>Transactional guarantees</h1>
18
 
<p>It is important to consider replication in the context of the overall
19
 
database environment's transactional guarantees.  To briefly review,
20
 
transactional guarantees in a non-replicated application are based on
21
 
the writing of log file records to "stable storage", usually a disk
22
 
drive.  If the application or system then fails, the Berkeley DB logging
23
 
information is reviewed during recovery, and the databases are updated
24
 
so that all changes made as part of committed transactions appear, and
25
 
all changes made as part of uncommitted transactions do not appear.  In
26
 
this case, no information will have been lost.
27
 
<p>If a database environment does not require that the log be flushed to
28
 
stable storage on transaction commit (using the <a href="../../api_c/env_set_flags.html#DB_TXN_NOSYNC">DB_TXN_NOSYNC</a>
29
 
flag to increase performance at the cost of sacrificing transactional
30
 
durability), Berkeley DB recovery will only be able to restore the system to
31
 
the state of the last commit found on stable storage.  In this case,
32
 
information may have been lost (for example, the changes made by some
33
 
committed transactions may not appear in the databases after recovery).
34
 
<p>Further, if there is database or log file loss or corruption (for
35
 
example, if a disk drive fails), then catastrophic recovery is
36
 
necessary, and Berkeley DB recovery will only be able to restore the system
37
 
to the state of the last archived log file.  In this case, information
38
 
may also have been lost.
39
 
<p>Replicating the database environment extends this model, by adding a
40
 
new component to "stable storage": the client's replicated information.
41
 
If a database environment is replicated, there is no lost information
42
 
in the case of database or log file loss, because the replicated system
43
 
can be configured to contain a complete set of databases and log records
44
 
up to the point of failure.  A database environment that loses a disk
45
 
drive can have the drive replaced, and it can rejoin the replication
46
 
group as a client.
47
 
<p>Because of this new component of stable storage, specifying
48
 
<a href="../../api_c/env_set_flags.html#DB_TXN_NOSYNC">DB_TXN_NOSYNC</a> in a replicated environment no longer sacrifices
49
 
durability, as long as one or more clients have acknowledged receipt of
50
 
the messages sent by the master.  Since network connections are often
51
 
faster than local disk writes, replication becomes a way for
52
 
applications to significantly improve their performance as well as their
53
 
reliability.
54
 
<p>The return status from the <b>send</b> interface specified to the
55
 
<a href="../../api_c/rep_transport.html">DB_ENV-&gt;set_rep_transport</a> method must be set by the application to ensure the
56
 
transactional guarantees the application wants to provide.  The effect
57
 
of the <b>send</b> interface returning failure is to flush the local
58
 
database environment's log as necessary to ensure that any information
59
 
critical to database integrity is not lost.  Because this flush is an
60
 
expensive operation in terms of database performance, applications will
61
 
want to avoid returning an error from the <b>send</b> interface, if at
62
 
all possible:
63
 
<p>First, there is no reason for the <b>send</b> interface to ever return
64
 
failure unless the <a href="../../api_c/rep_transport.html#DB_REP_PERMANENT">DB_REP_PERMANENT</a> flag is specified.  Messages
65
 
without that flag do not make visible changes to databases, and
66
 
therefore the application's <b>send</b> interface can return success
67
 
to Berkeley DB for such messages as soon as the message has been sent or even
68
 
just copied to local memory.
69
 
<p>Further, unless the master's database environment has been configured
70
 
to not synchronously flush the log on transaction commit, there is no
71
 
reason for the <b>send</b> interface to ever return failure, as any
72
 
information critical to database integrity has already been flushed to
73
 
the local log before <b>send</b> was called.  Again, the <b>send</b>
74
 
interface should return success to Berkeley DB as soon as possible.  However,
75
 
in this case, in order to avoid potential loss of information after the
76
 
master database environment fails, the master database environment
77
 
should be recovered before holding an election, as only the master
78
 
database environment is guaranteed to have the most up-to-date logs.
79
 
<p>To sum up, the only reason for the <b>send</b> interface to return
80
 
failure is when the master database environment has been configured to
81
 
not synchronously flush the log on transaction commit, the
82
 
<a href="../../api_c/rep_transport.html#DB_REP_PERMANENT">DB_REP_PERMANENT</a> flag is specified for the message, and the
83
 
<b>send</b> interface was unable to determine that some number of
84
 
clients have received the current message (and all messages preceding
85
 
the current message).  How many clients should receive the message
86
 
before the <b>send</b> interface can return success is an application
87
 
choice (and may not depend as much on a specific number of clients
88
 
reporting success as one or more geographically distributed clients).
89
 
<p>Of course, it is important to ensure that the replicated master and
90
 
client environments are truly independent of each other.  For example,
91
 
it does not help matters that a client has acknowledged receipt of a
92
 
message if both master and clients are on the same power supply, as the
93
 
failure of the power supply will still potentially lose information.
94
 
<p>Finally, the Berkeley DB replication implementation has one other additional
95
 
feature to increase application reliability.  Replication in Berkeley DB is
96
 
implemented to perform database updates using a different code path than
97
 
the standard ones.  This means operations which manage to crash the
98
 
replication master due to a software bug will not necessarily also crash
99
 
replication clients.
100
 
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/rep/logonly.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/rep/partition.html"><img src="../../images/next.gif" alt="Next"></a>
101
 
</td></tr></table>
102
 
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
103
 
</body>
104
 
</html>