← Back to branch summary

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

« back to all changes in this revision

Viewing changes to db/docs/ref/transapp/term.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/term.html
 
1
<!--$Id: term.so,v 10.18 2001/03/13 19:45:12 bostic Exp $-->
 
2
<!--Copyright 1997-2001 by Sleepycat Software, Inc.-->
 
3
<!--All rights reserved.-->
 
4
<html>
 
5
<head>
 
6
<title>Berkeley DB Reference Guide: Terminology</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
<table width="100%"><tr valign=top>
 
12
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Transactional Data Store Applications</dl></h3></td>
 
13
<td align=right><a href="../../ref/transapp/why.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/app.html"><img src="../../images/next.gif" alt="Next"></a>
 
14
</td></tr></table>
 
15
<p>
 
16
<h1 align=center>Terminology</h1>
 
17
<p>Here are some definitions that will be helpful in understanding
 
18
transactions:
 
19
<p><dl compact>
 
20
<p><dt>Thread of control<dd>Berkeley DB is indifferent to the type or style of threads being used by the
 
21
application; or, for that matter, if threads are being used at all --
 
22
because Berkeley DB supports multiprocess access.  In the Berkeley DB documentation,
 
23
any time we refer to a <i>thread of control</i>, it can be read as
 
24
a true thread (one of many in an application's address space) or a
 
25
process.
 
26
<p><dt>Free-threaded<dd>A Berkeley DB handle that can be used by multiple threads simultaneously
 
27
without any application-level synchronization is called
 
28
<i>free-threaded</i>.
 
29
<p><dt>Transaction<dd>A <i>transaction</i> is a one or more operations on one or more
 
30
databases that should be treated as a single unit of work.  For example,
 
31
changes to a set of databases, in which either all of the changes must be
 
32
applied to the database(s) or none of them should.  Applications specify
 
33
when each transaction starts, what database operations are included in
 
34
it, and when it ends.
 
35
<p><dt>Transaction abort/commit<dd>Every transaction ends by <i>committing</i> or <i>aborting</i>.
 
36
If a transaction commits, Berkeley DB guarantees that any database changes
 
37
included in the transaction will never be lost, even after system or
 
38
application failure.  If a transaction aborts, or is uncommitted when
 
39
the system or application fails, then the changes involved will never
 
40
appear in the database.
 
41
<p><dt>System or application failure<dd><i>System or application failure</i> is the phrase we use to
 
42
describe something bad happening near your data.  It can be an
 
43
application dumping core, being interrupted by a signal, the disk
 
44
filling up, or the entire system crashing.  In any case, for whatever
 
45
reason, the application can no longer make forward progress, and its
 
46
databases are left in an unknown state.
 
47
<p><dt>Recovery<dd><i>Recovery</i> is what makes the database consistent after a system
 
48
or application failure.  The recovery process includes review of log
 
49
files and databases to ensure that the changes from each committed
 
50
transaction appear in the database, and that no changes from an
 
51
unfinished (or aborted) transaction do.  Whenever system or application
 
52
failure occurs, applications must usually run recovery.
 
53
<p><dt>Deadlock<dd><i>Deadlock</i>, in its simplest form, happens when one thread of
 
54
control owns resource A, but needs resource B; while another thread of
 
55
control owns resource B, but needs resource A.  Neither thread of
 
56
control can make progress, and so one has to give up and release all
 
57
its resources, at which time the remaining thread of control can make
 
58
forward progress.
 
59
</dl>
 
60
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/transapp/why.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/app.html"><img src="../../images/next.gif" alt="Next"></a>
 
61
</td></tr></table>
 
62
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
 
63
</body>
 
64
</html>