For more information, see Architecting Data Store and Concurrent Data Store applications, and Architecting Transactional Data Store applications, both in the Berkeley DB Programmer's Reference Guide.

FailCheck is based on the SetThreadID and ThreadIsAlive delegates. Applications calling FailCheck must have already set ThreadIsAlive, and must have configured ThreadCount.

If FailCheck determines a thread of control exited while holding database read locks, it releases those locks. If FailCheck determines a thread of control exited with an unresolved transaction, the transaction aborts. In either of these cases, FailCheck returns successfully and the application may continue to use the database environment.

In either of these cases, FailCheck also reports the process and thread IDs associated with any released locks or aborted transactions. The information is printed to a specified output channel (see Verbosity for more information), or passed to an application delegate (see Feedback for more information).

If FailCheck determines a thread of control has exited such that database environment recovery is required, it throws RunRecoveryException. In this case, the application should not continue to use the database environment. For a further description as to the actions the application should take when this failure occurs, see Handling failure in Data Store and Concurrent Data Store applications, and Handling failure in Transactional Data Store applications, both in the Berkeley DB Programmer's Reference Guide.