#include <db.h>

u_int32_t
DB_TXN->set_timeout(DB_TXN *tid, db_timeout_t timeout, u_int32_t flags);

Description

The DB_TXN->set_timeout method sets timeout values for locks or transactions for the specified transaction. The timeout value is currently specified as an unsigned 32-bit number of microseconds, limiting the maximum timeout to roughly 71 minutes.

The flags value must be set to one of the following values:

DB_SET_LOCK_TIMEOUT

Set the timeout value for locks in this transaction.

DB_SET_TXN_TIMEOUT

Set the timeout value for this transaction.

Timeouts are checked whenever a thread of control blocks on a lock or when deadlock detection is performed. (In the case of DB_SET_LOCK_TIMEOUT, the lock is one requested explicitly through the Lock subsystem interfaces. In the case of DB_SET_TXN_TIMEOUT, the lock is one requested on behalf of a transaction. In either case, it may be a lock requested by the database access methods underlying the application.) As timeouts are only checked when the lock request first blocks or when deadlock detection is performed, the accuracy of the timeout depends on how often deadlock detection is performed.

Timeout values may be specified for the database environment as a whole. See DB_ENV->set_timeout and for more information.

The DB_TXN->set_timeout method configures operations performed on the underlying transaction, not only operations performed using the specified DB_TXN handle.

The DB_TXN->set_timeout interface may be called at any time during the life of the application.

The DB_TXN->set_timeout method returns a non-zero error value on failure and 0 on success.

Errors

The DB_TXN->set_timeout method may fail and return a non-zero error for the following conditions:

EINVAL

An invalid flag value or parameter was specified.

The DB_TXN->set_timeout method may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. If a catastrophic error has occurred, the DB_TXN->set_timeout method may fail and return DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail in the same way.

Class

See Also