From 780b92ada9afcf1d58085a83a0b9e6bc982203d1 Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Tue, 17 Feb 2015 17:25:57 +0000 Subject: Imported from /home/lorry/working-area/delta_berkeleydb/db-6.1.23.tar.gz. --- docs/programmer_reference/am_close.html | 63 ++++++++++++++++++++++----------- 1 file changed, 42 insertions(+), 21 deletions(-) (limited to 'docs/programmer_reference/am_close.html') diff --git a/docs/programmer_reference/am_close.html b/docs/programmer_reference/am_close.html index 3cc0a30e..50a7a1de 100644 --- a/docs/programmer_reference/am_close.html +++ b/docs/programmer_reference/am_close.html @@ -14,7 +14,7 @@

Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 3. - Access Method Operations -	Chapter 3. Access Method Operations	Next

@@ -38,10 +36,15 @@

The DB->close() database handle closes the DB handle. By -default, DB->close() also flushes all modified records from the -database cache to disk.

There is one flag that you can set to customize DB->close():

+ The DB->close() database handle closes the DB handle. By + default, DB->close() also flushes all modified records from the + database cache to disk. +

+ There is one flag that you can set to customize + DB->close(): +

@@ -49,25 +52,43 @@ database cache to disk. DB_NOSYNC: Do not flush cached information to disk.; + Do not flush cached information to + disk. +

- 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. + + 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. + -

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:

+ 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: +

Use transactions and logging with automatic recovery.
Use logging and application-specific recovery.
Edit a copy of the database, and, once all applications -using the database have successfully called DB->close(), use -system operations (for example, the POSIX rename system call) to -atomically replace the original database with the updated copy.
+ Use transactions and logging with automatic + recovery. +
+ Use logging and application-specific + recovery. +
+ Edit a copy of the database, and, once all + applications using the database have successfully called + DB->close(), use system operations (for example, the POSIX + rename system call) to atomically replace the original + database with the updated copy. +

-- cgit v1.2.1