- Berkeley DB Reference Guide:
- Locking Subsystem
|
|
If an application runs with locking specified, but not transactions (e.g., DBENV->open is called with DB_INIT_LOCK or DB_INIT_CDB specified, but not DB_INIT_TXN), locks are normally acquired during each Berkeley DB operation and released before the operation returns to the caller. The only exception is in the case of cursor operations. As cursors identify a particular position in a file, a cursor must retain a read-lock across cursor calls to make sure that that position is uniquely identifiable during the next cursor call, because an operation using DB_CURRENT must reference the same record as the previous cursor call. Such cursor locks cannot be released until either the cursor is reset using the DB_GET_BOTH, DB_SET, DB_SET_RANGE, DB_KEYFIRST, or DB_KEYLAST functionality, in which case a new cursor lock is established, or the cursor is closed. As a result, application designers are encouraged to close cursors as soon as possible.
It is important to realize that concurrent applications that use locking must ensure that two concurrent threads do not interfere with each other. However, as Btree and Hash access method page splits can occur at any time, there is virtually no way to guarantee that an application which writes the database cannot deadlock. Applications running without the protection of transactions may deadlock, and when they do so, can leave the database in an inconsistent state. Applications that need concurrent access, but not transactions, are more safely implemented using the Berkeley DB Concurrent Data Store Product.
|
|