You initialize the locking subsystem by specifying DB_INIT_LOCK to the DbEnv::open() method.

Before opening your environment, you can configure various maximum values for your locking subsystem. Note that these limits can only be configured before the environment is opened. Also, these methods configure the entire environment, not just a specific environment handle.

Finally, each bullet below identifies the DB_CONFIG file parameter that can be used to specify the specific locking limit. If used, these DB_CONFIG file parameters override any value that you might specify using the environment handle.

The limits that you can configure are as follows:

For a definition of lockers, locks, and locked objects, see Lock Resources.

For example, to configure the maximum number of locks that your environment can use:

#include "db_cxx.h"

...
                                                                                                                                  
int main(void)
{
    u_int32_t env_flags = DB_CREATE     |  // If the environment does not
                                           // exist, create it.
                          DB_INIT_LOCK  |  // Initialize locking
                          DB_INIT_LOG   |  // Initialize logging
                          DB_INIT_MPOOL |  // Initialize the cache
                          DB_THREAD     |  // Free-thread the env handle.
                          DB_INIT_TXN;     // Initialize transactions
                                                                                                                                  
    std::string envHome("/export1/testEnv");
    DbEnv myEnv(0);

    try {

        // Configure max locks
        myEnv.set_lk_max_locks(envp, 5000);

        myEnv.open(envHome.c_str(), env_flags, 0);

    } catch(DbException &e) {
        std::cerr << "Error opening database environment: "
                  << envHome << std::endl;
        std::cerr << e.what() << std::endl;
        return (EXIT_FAILURE);
    }

    try {
        myEnv.close(0);
    } catch(DbException &e) {
        std::cerr << "Error closing database environment: "
                << envHome << std::endl;
        std::cerr << e.what() << std::endl;
        return (EXIT_FAILURE);
    }

    return (EXIT_SUCCESS);
} 

In order for JE to know that a deadlock has occurred, some mechanism must be used to perform deadlock detection. There are three ways that deadlock detection can occur:

For example, to configure your application such that JE checks the lock table for deadlocks every time a lock request is blocked:

#include "db_cxx.h"

...
                                                                                                                                  
int main(void)
{
    u_int32_t env_flags = DB_CREATE     |  // If the environment does not
                                           // exist, create it.
                          DB_INIT_LOCK  |  // Initialize locking
                          DB_INIT_LOG   |  // Initialize logging
                          DB_INIT_MPOOL |  // Initialize the cache
                          DB_THREAD     |  // Free-thread the env handle
                          DB_INIT_TXN;     // Initialize transactions

    std::string envHome("/export1/testEnv");
    DbEnv myEnv(0);

    try {

        // Configure db to perform deadlock detection internally, and to
        // choose the transaction that has performed the least amount 
        // of writing to break the deadlock in the event that one 
        // is detected.
        myEnv.set_lk_detect(DB_LOCK_MINWRITE);
        myEnv.open(envHome.c_str(), env_flags, 0);
     
        // From here, you open your databases, proceed with your 
        // database operations, and respond to deadlocks as 
        // is normal (omitted for brevity).

        
        ...

Finally, the following command line call causes deadlock detection to be run against the environment contained in /export/dbenv. The transaction with the youngest lock is chosen to break the deadlock:

> /usr/local/db_install/bin/db_deadlock -h /export/dbenv -a y

For more information, see the db_deadlock reference documentation.

When JE determines that a deadlock has occurred, it will select a thread of control to resolve the deadlock and then throws DbDeadlockException in that thread. If a deadlock is detected, the thread must:

For example:

// retry_count is a counter used to identify how many times
// we've retried this operation. To avoid the potential for 
// endless looping, we won't retry more than MAX_DEADLOCK_RETRIES 
// times.

// txn is a transaction handle.
// key and data are DBT handles. Their usage is not shown here.
while (retry_count < MAX_DEADLOCK_RETRIES) {
    try {
        envp->txn_begin(NULL, txn, 0);
        dbp->put(txn, &key, &data, 0);
        txn->commit(0);
    } catch (DbDeadlockException &de) {
        try {
            // Abort the transaction and increment the 
            // retry counter
            txn->abort();
            retry_count++;
            // If we've retried too many times, log it and exit
            if (retry_count >= MAX_DEADLOCK_RETRIES) {
                    envp->errx("Exceeded retry limit. Giving up.");
                    return (EXIT_FAILURE);
            }
        } catch (DbException &ae) {
            envp->err(ae.get_errno(), "txn abort failed.");
            return (EXIT_FAILURE);    
        }
    } catch (DbException &e) {
        try {
            // For a generic error, log it and abort.
            envp->err(e.get_errno(), "Error putting data.");
            txn->abort();
        } catch (DbException &ae) {
            envp->err(ae.get_errno(), "txn abort failed.");
            return (EXIT_FAILURE);    
        }
    }
}

return (EXIT_SUCCESS);