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 will release those locks. If FailCheck determines a thread of control exited with an unresolved transaction, the transaction will be aborted. In either of these cases, FailCheck will return successfully and the application may continue to use the database environment.

In either of these cases, FailCheck will also report 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 will throw 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.