mirror of
https://github.com/berkeleydb/je.git
synced 2024-11-15 01:46:24 +00:00
113 lines
5.3 KiB
HTML
113 lines
5.3 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|||
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|||
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|||
|
<head>
|
|||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
|||
|
<title>A Note on System Failure</title>
|
|||
|
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
|
|||
|
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
|
|||
|
<link rel="start" href="index.html" title="Getting Started with Berkeley DB, Java Edition Transaction Processing" />
|
|||
|
<link rel="up" href="introduction.html" title="Chapter 1. Introduction" />
|
|||
|
<link rel="prev" href="introduction.html" title="Chapter 1. Introduction" />
|
|||
|
<link rel="next" href="apireq.html" title="Application Requirements" />
|
|||
|
</head>
|
|||
|
<body>
|
|||
|
<div xmlns="" class="navheader">
|
|||
|
<div class="libver">
|
|||
|
<p>Library Version 12.2.7.5</p>
|
|||
|
</div>
|
|||
|
<table width="100%" summary="Navigation header">
|
|||
|
<tr>
|
|||
|
<th colspan="3" align="center">A Note on System Failure</th>
|
|||
|
</tr>
|
|||
|
<tr>
|
|||
|
<td width="20%" align="left"><a accesskey="p" href="introduction.html">Prev</a> </td>
|
|||
|
<th width="60%" align="center">Chapter 1. Introduction</th>
|
|||
|
<td width="20%" align="right"> <a accesskey="n" href="apireq.html">Next</a></td>
|
|||
|
</tr>
|
|||
|
</table>
|
|||
|
<hr />
|
|||
|
</div>
|
|||
|
<div class="sect1" lang="en" xml:lang="en">
|
|||
|
<div class="titlepage">
|
|||
|
<div>
|
|||
|
<div>
|
|||
|
<h2 class="title" style="clear: both"><a id="sysfailure"></a>A Note on System Failure</h2>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
From time to time this manual mentions that transactions
|
|||
|
protect your data against 'system or application failure.' This
|
|||
|
is true up to a certain extent. However, not all failures are
|
|||
|
created equal and no data protection mechanism can protect you
|
|||
|
against every conceivable way a computing system can find to
|
|||
|
die.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
Generally, when this book talks about protection against
|
|||
|
failures, it means that transactions offer protection against
|
|||
|
the likeliest culprits for system and application crashes. So
|
|||
|
long as your data modifications have been committed to disk,
|
|||
|
those modifications should persist even if your application or
|
|||
|
OS subsequently fails. And, even if the application or OS
|
|||
|
fails in the middle of a transaction commit (or abort), the
|
|||
|
data on disk should be either in a consistent state, or there
|
|||
|
should be enough data available to bring your databases into a
|
|||
|
consistent state (via a recovery procedure, for example). You
|
|||
|
may, however, lose whatever data you were committing at the
|
|||
|
time of the failure, but your databases will be otherwise
|
|||
|
unaffected.
|
|||
|
</p>
|
|||
|
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
|||
|
<h3 class="title">Note</h3>
|
|||
|
<p>
|
|||
|
Be aware that many disks have a disk write cache and on
|
|||
|
some systems it is enabled by default. This means that
|
|||
|
a transaction can have committed, and to your
|
|||
|
application the data may appear to reside on disk, but
|
|||
|
the data may in fact reside only in the write cache at
|
|||
|
that time. This means that if the disk write cache is
|
|||
|
enabled and there is no battery backup for it, data can
|
|||
|
be lost after an OS crash even when maximum durability
|
|||
|
mode is in use. For maximum durability, disable the
|
|||
|
disk write cache or use a disk write cache with a
|
|||
|
battery backup.
|
|||
|
</p>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
Of course, if your <span class="emphasis"><em>disk</em></span> fails, then the transactional benefits described in this book
|
|||
|
are only as good as the backups you have taken.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
Finally, by following the programming examples shown in this book, you can write your code so as to protect
|
|||
|
your data in the event that your code crashes. However, no programming API can protect you against logic
|
|||
|
failures in your own code; transactions cannot protect you from simply writing the wrong thing to your
|
|||
|
databases.
|
|||
|
</p>
|
|||
|
</div>
|
|||
|
<div class="navfooter">
|
|||
|
<hr />
|
|||
|
<table width="100%" summary="Navigation footer">
|
|||
|
<tr>
|
|||
|
<td width="40%" align="left"><a accesskey="p" href="introduction.html">Prev</a> </td>
|
|||
|
<td width="20%" align="center">
|
|||
|
<a accesskey="u" href="introduction.html">Up</a>
|
|||
|
</td>
|
|||
|
<td width="40%" align="right"> <a accesskey="n" href="apireq.html">Next</a></td>
|
|||
|
</tr>
|
|||
|
<tr>
|
|||
|
<td width="40%" align="left" valign="top">Chapter 1. Introduction </td>
|
|||
|
<td width="20%" align="center">
|
|||
|
<a accesskey="h" href="index.html">Home</a>
|
|||
|
</td>
|
|||
|
<td width="40%" align="right" valign="top"> Application Requirements</td>
|
|||
|
</tr>
|
|||
|
</table>
|
|||
|
</div>
|
|||
|
</body>
|
|||
|
</html>
|