When running with threaded handles (i.e., specifying DB_THREAD
to DBENV->open or DB->open), you must specify one of those
flags for all DBT structures in which Berkeley DB is returning data.
Symptom:
Running multiple threads or processes, and the database appears to be
getting corrupted.
Possible Cause:
Locking is not enabled.
Fix:
Make sure that you are acquiring locks in your access methods. You
must specify DB_INIT_LOCK to your DBENV->open call and then
pass that environment to DB->open.
Symptom:
Locks are accumulating or threads and/or processes are
deadlocking even though there is no concurrent access to the database.
Possible Cause:
Failure to close a cursor.
Fix:
Cursors retain locks between calls. Everywhere the application uses
a cursor, the cursor should be explicitly closed as soon as possible after
it is used.
Unless you are using the Concurrent Data Store product, whenever you
have multiple threads and/or processes and at least one of them is
writing, you have the potential for deadlock. As a result, you must
test for the DB_LOCK_DEADLOCK return on every Berkeley DB call. In
general, updates should take place in a transaction or you might leave
the database in an inconsistent state. Reads may take place outside
the context of a transaction under common conditions.
Read-Modify-Write pattern without using the RMW flag.
Fix:
If you frequently read a piece of data, modify it and then write
it, you may be inadvertently causing a large number of deadlocks. Try
specifying the DB_RMW flag on your get calls.
Or, if the application is doing a large number of updates in a small
database, turning off Btree splits may help (see DB_REVSPLITOFF
for more information.)
Symptom:
I run recovery and it exits cleanly, but my database changes are missing.
Possible Cause:
Failure to enable logging and transactions in the database environment,
failure to specify DB_ENV handle when creating DB handle,
transaction handle not passed to Berkeley DB interface, failure to commit
transaction.
Fix:
Make sure that the environment and database handles are properly
created, and that the application passes the transaction handle returned
by txn_begin to the appropriate Berkeley DB interfaces, and that each
transaction is eventually committed.
Symptom:
Recovery fails.
Possible Cause:
A database was updated in a transactional environment both with and
without transactional handles.
Fix:
If any database write operation is done using a transaction handle,
every write operation must be done in the context of a transaction.
Symptom:
A database environment locks up, sometimes gradually.
Possible Cause:
A thread of control exited unexpectedly, holding Berkeley DB resources.
Fix:
Whenever a thread of control exits holding Berkeley DB resources, all threads
of control must exit the database environment, and recovery must be run.
Symptom:
A database environment locks up, sometimes gradually.
Possible Cause:
Cursors are not being closed before transaction abort.
Fix:
Before an application aborts a transaction, any cursors opened within
the context of that transaction must be closed.
Symptom:
Transaction abort or recovery fail, or database corruption occurs.
Possible Cause:
Log files were removed before it was safe.
Fix:
Do not remove any log files from a database environment until Berkeley DB
declares it safe.