File: sync.html

package info (click to toggle)
evolution-data-server 1.0.4-1
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 39,504 kB
  • ctags: 26,423
  • sloc: ansic: 175,347; tcl: 30,499; sh: 20,699; perl: 11,320; xml: 9,039; java: 7,653; cpp: 6,029; makefile: 4,866; awk: 1,338; yacc: 1,103; sed: 772; cs: 505; lex: 134; asm: 14
file content (39 lines) | stat: -rw-r--r-- 2,466 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
<!--$Id: sync.html,v 1.1.1.1 2003/11/20 22:14:08 toshok Exp $-->
<!--Copyright 1997-2002 by Sleepycat Software, Inc.-->
<!--All rights reserved.-->
<!--See the file LICENSE for redistribution information.-->
<html>
<head>
<title>Berkeley DB Reference Guide: Flushing the database cache</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++">
</head>
<body bgcolor=white>
<a name="2"><!--meow--></a>
<table width="100%"><tr valign=top>
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Access Methods</dl></h3></td>
<td align=right><a href="../../ref/am/verify.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/am/close.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
<p>
<h1 align=center>Flushing the database cache</h1>
<p>The <a href="../../api_c/db_sync.html">DB-&gt;sync</a> method is the standard interface for flushing all modified
records from the database cache to disk.
<p><b>It is important to understand that flushing cached information
to disk only minimizes the window of opportunity for corrupted data, it
does not eliminate the possibility.</b>
<p>While unlikely, it is possible for database corruption to happen if a
system or application crash occurs while writing data to the database. To
ensure that database corruption never occurs, applications must either:
<p><ul type=disc>
<li>Use transactions and logging with automatic recovery.
<li>Use logging and application-specific recovery.
<li>Edit a copy of the database, and, once all applications
using the database have successfully called <a href="../../api_c/db_close.html">DB-&gt;close</a>, use
system operations (for example, the POSIX rename system call) to
atomically replace the original database with the updated copy.
</ul>
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/am/verify.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/am/close.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
</body>
</html>