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/transapp_fail.html | 159 +++++++++++++++------------ 1 file changed, 91 insertions(+), 68 deletions(-) (limited to 'docs/programmer_reference/transapp_fail.html') diff --git a/docs/programmer_reference/transapp_fail.html b/docs/programmer_reference/transapp_fail.html index 1ac9442f..f58cfb20 100644 --- a/docs/programmer_reference/transapp_fail.html +++ b/docs/programmer_reference/transapp_fail.html @@ -14,7 +14,7 @@

Library Version 11.2.5.3

Library Version 12.1.6.1

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

Prev	Chapter 11. - Berkeley DB Transactional Data Store Applications -	Chapter 11. Berkeley DB Transactional Data Store Applications	Next

@@ -38,77 +36,101 @@

- When building Transactional Data Store applications, there are design - issues to consider whenever a thread of control with open Berkeley DB - handles fails for any reason (where a thread of control may be either a - true thread or a process). -

- The first case is handling system failure: if the system fails, the - database environment and the databases may be left in a corrupted - state. In this case, recovery must be performed on the database - environment before any further action is taken, in order to: -

+ When building Transactional Data Store applications, there + are design issues to consider whenever a thread of control + with open Berkeley DB handles fails for any reason (where a + thread of control may be either a true thread or a process). +

+ The first case is handling system failure: if the system + fails, the database environment and the databases may be left + in a corrupted state. In this case, recovery must be performed + on the database environment before any further action is + taken, in order to: +

recover the database environment resources,
release any locks or mutexes that may have been held to avoid starvation -as the remaining threads of control convoy behind the held locks, and
resolve any partially completed operations that may have left a database -in an inconsistent or corrupted state.
+ recover the database environment + resources, +
+ release any locks or mutexes that may have been held + to avoid starvation as the remaining threads of control + convoy behind the held locks, and +
+ resolve any partially completed operations that may + have left a database in an inconsistent or corrupted + state. +

- For details on performing recovery, see the - Recovery procedures. -

- The second case is handling the failure of a thread of control. There - are resources maintained in database environments that may be left - locked or corrupted if a thread of control exits unexpectedly. These - resources include data structure mutexes, logical database locks and - unresolved transactions (that is, transactions which were never aborted - or committed). While Transactional Data Store applications can treat - the failure of a thread of control in the same way as they do a system - failure, they have an alternative choice, the DB_ENV->failchk() method. -

+ For details on performing recovery, see the Recovery procedures. +

- The DB_ENV->failchk() will return - DB_RUNRECOVERY - if the database - environment is unusable as a result of the thread of control failure. - (If a data structure mutex or a database write lock is left held by - thread of control failure, the application should not continue to use - the database environment, as subsequent use of the environment is - likely to result in threads of control convoying behind the held - locks.) The DB_ENV->failchk() call will release any database read locks - that have been left held by the exit of a thread of control, and abort - any unresolved transactions. In this case, the application can - continue to use the database environment. -

+ The second case is handling the failure of a thread of + control. There are resources maintained in database + environments that may be left locked or corrupted if a thread + of control exits unexpectedly. These resources include data + structure mutexes, logical database locks and unresolved + transactions (that is, transactions which were never aborted + or committed). While Transactional Data Store applications can + treat the failure of a thread of control in the same way as + they do a system failure, they have an alternative choice, the + DB_ENV->failchk() method. +

+ The DB_ENV->failchk() method will return + DB_RUNRECOVERY + if the database environment is unusable as a result of the thread + of control failure. (If a data structure mutex or a database write + lock is left held by thread of control failure, the application + should not continue to use the database environment, as subsequent + use of the environment is likely to result in threads of control + convoying behind the held locks.) The DB_ENV->failchk() call will + release any database read locks that have been left held by the + exit of a thread of control, and abort any unresolved transactions. + In this case, the application can continue to use the database + environment. +

- A Transactional Data Store application recovering from a thread of - control failure should call DB_ENV->failchk(), and, if it returns success, - the application can continue. If DB_ENV->failchk() returns - DB_RUNRECOVERY, - the application should proceed as described for - the case of system failure. -

+ Note that you can optionally cause DB_ENV->failchk() to broadcast a database + environment failure to other threads of control by using the + --enable-failchk_broadcast flag when you compile + your Berkeley DB library. If this option is turned on, then all + threads of control using the database environment will return + DB_RUNRECOVERY + when they attempt to obtain a mutex lock. In this situation, a + DB_EVENT_FAILCHK_PANIC or + DB_EVENT_MUTEX_DIED event will also be raised. + (You use DB_ENV->set_event_notify() to examine events). +

+ A Transactional Data Store application recovering from a + thread of control failure should call DB_ENV->failchk(), and, if it + returns success, the application can continue. If DB_ENV->failchk() + returns DB_RUNRECOVERY, + the application should proceed as described for the case of system + failure. In addition, threads notified of failure by DB_ENV->failchk() + should also proceed as described for the case of system failure. +

- It greatly simplifies matters that recovery may be performed regardless - of whether recovery needs to be performed; that is, it is not an error - to recover a database environment for which recovery is not strictly - necessary. For this reason, applications should not try to determine - if the database environment was active when the application or system - failed. Instead, applications should run recovery any time the - DB_ENV->failchk() method returns - DB_RUNRECOVERY, - or, if the application is - not calling the DB_ENV->failchk() method, any time any thread of control - accessing the database environment fails, as well as any time the - system reboots. -

+ It greatly simplifies matters that recovery may be + performed regardless of whether recovery needs to be + performed; that is, it is not an error to recover a database + environment for which recovery is not strictly necessary. For + this reason, applications should not try to determine if the + database environment was active when the application or system + failed. Instead, applications should run recovery any time the + DB_ENV->failchk() method returns + DB_RUNRECOVERY, or, if the application is not + calling the DB_ENV->failchk() method, any time any thread of + control accessing the database environment fails, as well as + any time the system reboots. +

@@ -125,7 +147,8 @@ in an inconsistent or corrupted state. Home - Architecting Transactional Data Store applications + Architecting Transactional Data + Store applications

-- cgit v1.2.1