#include <db.h>

int
DB_ENV->failchk(DB_ENV *dbenv, u_int32_t flags);  

The DB_ENV->failchk() method checks for threads of control (either a true thread or a process) that have exited while manipulating Berkeley DB library data structures, while holding a logical database lock, or with an unresolved transaction (that is, a transaction that was never aborted or committed). 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.

The DB_ENV->failchk() method is based on the thread_id and is_alive functions specified to the DB_ENV->set_thread_id() and DB_ENV->set_isalive() methods. Applications calling the DB_ENV->failchk() method must have already called the DB_ENV->set_isalive() method, on the same DB_ENV, and must have configured their database environment using the DB_ENV->set_thread_count() method.

If DB_ENV->failchk() determines a thread of control exited while holding database read locks, it will release those locks. If DB_ENV->failchk() determines a thread of control exited with an unresolved transaction, the transaction will be aborted. In either of these cases, DB_ENV->failchk() will return 0 and the application may continue to use the database environment.

In either of these cases, the DB_ENV->failchk() method 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 the DB_ENV->set_msgfile() method for more information), or passed to an application callback function (see the DB_ENV->set_msgcall() method for more information).

If DB_ENV->failchk() determines a thread of control has exited such that database environment recovery is required, it will return DB_RUNRECOVERY. 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.

In multiprocess applications, it is recommended that the DB_ENV handle used to invoke the DB_ENV->failchk() method not be shared and therefore not free-threaded.

The DB_ENV->failchk() method may not be called by the application before the DB_ENV->open() method is called.

The DB_ENV->failchk() method returns a non-zero error value on failure and 0 on success.