Library Version 11.2.5.3

Library Version 12.1.6.1

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

Prev	Chapter 11. - Berkeley DB Transactional Data Store Applications -	Chapter 11. Berkeley DB Transactional Data Store Applications	Next

@@ -38,58 +36,63 @@

- The first component of the infrastructure, - deadlock detection, is not so much a - requirement specific to transaction-protected applications, but instead - is necessary for almost all applications in which more than a single - thread of control will be accessing the database at one time. Even - when Berkeley DB automatically handles database locking, it is normally - possible for deadlock to occur. Because the underlying database access - methods may update multiple pages during a single Berkeley DB API call, - deadlock is possible even when threads of control are making only - single update calls into the database. The exception to this rule is - when all the threads of control accessing the database are read-only or - when the Berkeley DB Concurrent Data Store product is used; the - Berkeley DB Concurrent Data Store product guarantees deadlock-free - operation at the expense of reduced concurrency. -

- When the deadlock occurs, two (or more) threads of control each request - additional locks that can never be granted because one of the threads - of control waiting holds the requested resource. For example, consider - two processes: A and B. Let's say that A obtains a write lock on item - X, and B obtains a write lock on item Y. Then, A requests a lock on Y, - and B requests a lock on X. A will wait until resource Y becomes - available and B will wait until resource X becomes available. - Unfortunately, because both A and B are waiting, neither will release - the locks they hold and neither will ever obtain the resource on which - it is waiting. For another example, consider two transactions, A and - B, each of which may want to modify item X. Assume that transaction A - obtains a read lock on X and confirms that a modification is needed. - Then it is descheduled and the thread containing transaction B runs. - At that time, transaction B obtains a read lock on X and confirms that - it also wants to make a modification. Both transactions A and B will - block when they attempt to upgrade their read locks to write locks - because the other already holds a read lock. This is a deadlock. - Transaction A cannot make forward progress until Transaction B releases - its read lock on X, but Transaction B cannot make forward progress - until Transaction A releases its read lock on X. -

- In order to detect that deadlock has happened, a separate process or - thread must review the locks currently held in the database. If - deadlock has occurred, a victim must be selected, and that victim will - then return the error - DB_LOCK_DEADLOCK - from whatever Berkeley DB call it was making. Berkeley DB provides the - db_deadlock utility that can be used to perform this deadlock detection. - Alternatively, applications can create their own deadlock utility or - thread using the underlying DB_ENV->lock_detect() function, or specify that - Berkeley DB run the deadlock detector internally whenever there is a - conflict over a lock (see DB_ENV->set_lk_detect() for more information). - The following code fragment does the latter: -

+ The first component of the infrastructure, + deadlock detection, is not so much a + requirement specific to transaction-protected applications, + but instead is necessary for almost all applications in which + more than a single thread of control will be accessing the + database at one time. Even when Berkeley DB automatically + handles database locking, it is normally possible for deadlock + to occur. Because the underlying database access methods may + update multiple pages during a single Berkeley DB API call, + deadlock is possible even when threads of control are making + only single update calls into the database. The exception to + this rule is when all the threads of control accessing the + database are read-only or when the Berkeley DB Concurrent Data + Store product is used; the Berkeley DB Concurrent Data Store + product guarantees deadlock-free operation at the expense of + reduced concurrency. +

+ When the deadlock occurs, two (or more) threads of control + each request additional locks that can never be granted + because one of the threads of control waiting holds the + requested resource. For example, consider two processes: A and + B. Let's say that A obtains a write lock on item X, and B + obtains a write lock on item Y. Then, A requests a lock on Y, + and B requests a lock on X. A will wait until resource Y + becomes available and B will wait until resource X becomes + available. Unfortunately, because both A and B are waiting, + neither will release the locks they hold and neither will ever + obtain the resource on which it is waiting. For another + example, consider two transactions, A and B, each of which may + want to modify item X. Assume that transaction A obtains a + read lock on X and confirms that a modification is needed. + Then it is descheduled and the thread containing transaction B + runs. At that time, transaction B obtains a read lock on X and + confirms that it also wants to make a modification. Both + transactions A and B will block when they attempt to upgrade + their read locks to write locks because the other already + holds a read lock. This is a deadlock. Transaction A cannot + make forward progress until Transaction B releases its read + lock on X, but Transaction B cannot make forward progress + until Transaction A releases its read lock on X. +

+ In order to detect that deadlock has happened, a separate + process or thread must review the locks currently held in the + database. If deadlock has occurred, a victim must be selected, + and that victim will then return the error DB_LOCK_DEADLOCK from + whatever Berkeley DB call it was making. Berkeley DB provides the db_deadlock utility that + can be used to perform this deadlock detection. Alternatively, + applications can create their own deadlock utility or thread + using the underlying DB_ENV->lock_detect() function, or specify that + Berkeley DB run the deadlock detector internally whenever + there is a conflict over a lock (see DB_ENV->set_lk_detect() for + more information). The following code fragment does the + latter: +

- Deciding how often to run the deadlock detector and which of the - deadlocked transactions will be forced to abort when the deadlock is - detected is a common tuning parameter for Berkeley DB applications. -

+ Deciding how often to run the deadlock detector and which + of the deadlocked transactions will be forced to abort when + the deadlock is detected is a common tuning parameter for + Berkeley DB applications. +

@@ -147,7 +151,8 @@ env_open(DB_ENV **dbenvp) Next - Environment infrastructure + Environment + infrastructure Home -- cgit v1.2.1