Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 16. - The Locking Subsystem -	Chapter 16. The Locking Subsystem	Next

@@ -38,30 +36,38 @@

If an application runs with locking specified, but not transactions (for -example, DB_ENV->open() is callsed 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. Cursors identify a particular position in a file. -For this reason, cursors must retain read locks across cursor calls to -make sure that the position is uniquely identifiable during a subsequent -cursor call, and so that an operation using DB_CURRENT will -always refer to the same record as a previous cursor call. These cursor -locks cannot be released until the cursor is either repositioned and a -new cursor lock established (for example, using the DB_NEXT -or DB_SET flags), or the cursor is closed. As a result, -application writers 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 block each other. -However, because Btree and Hash access method page splits can occur at -any time, there is virtually no way to guarantee that an application -that writes the database cannot deadlock. Applications running without -the protection of transactions may deadlock, and can leave the database -in an inconsistent state when they do so. Applications that need -concurrent access, but not transactions, are more safely implemented -using the Berkeley DB Concurrent Data Store Product.

+ If an application runs with locking specified, but not + transactions (for example, DB_ENV->open() is callsed 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. Cursors identify a particular position in a + file. For this reason, cursors must retain read locks across + cursor calls to make sure that the position is uniquely + identifiable during a subsequent cursor call, and so that an + operation using DB_CURRENT will always refer to the same + record as a previous cursor call. These cursor locks cannot be + released until the cursor is either repositioned and a new + cursor lock established (for example, using the DB_NEXT or + DB_SET flags), or the cursor is closed. As a result, + application writers 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 + block each other. However, because Btree and Hash access + method page splits can occur at any time, there is virtually + no way to guarantee that an application that writes the + database cannot deadlock. Applications running without the + protection of transactions may deadlock, and can leave the + database in an inconsistent state when they do so. + Applications that need concurrent access, but not + transactions, are more safely implemented using the Berkeley + DB Concurrent Data Store Product. +

@@ -78,7 +84,8 @@ using the Berkeley DB Concurrent Data Store Product.

Home - Locking with transactions: two-phase locking + Locking with transactions: two-phase + locking