diff options
Diffstat (limited to 'docs/programmer_reference/transapp_deadlock.html')
| -rw-r--r-- | docs/programmer_reference/transapp_deadlock.html | 129 |
1 files changed, 67 insertions, 62 deletions
diff --git a/docs/programmer_reference/transapp_deadlock.html b/docs/programmer_reference/transapp_deadlock.html index d457745c..e0a0ceb8 100644 --- a/docs/programmer_reference/transapp_deadlock.html +++ b/docs/programmer_reference/transapp_deadlock.html @@ -14,7 +14,7 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> @@ -22,9 +22,7 @@ </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="transapp_admin.html">Prev</a> </td> - <th width="60%" align="center">Chapter 11. - Berkeley DB Transactional Data Store Applications - </th> + <th width="60%" align="center">Chapter 11. Berkeley DB Transactional Data Store Applications </th> <td width="20%" align="right"> <a accesskey="n" href="transapp_checkpoint.html">Next</a></td> </tr> </table> @@ -38,58 +36,63 @@ </div> </div> </div> - <p> - The first component of the infrastructure, - <span class="emphasis"><em>deadlock detection</em></span>, 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. -</p> - <p> - 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. -</p> - <p> - 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 - <a class="link" href="program_errorret.html#program_errorret.DB_LOCK_DEADLOCK">DB_LOCK_DEADLOCK</a> - from whatever Berkeley DB call it was making. Berkeley DB provides the - <a href="../api_reference/C/db_deadlock.html" class="olink">db_deadlock</a> utility that can be used to perform this deadlock detection. - Alternatively, applications can create their own deadlock utility or - thread using the underlying <a href="../api_reference/C/lockdetect.html" class="olink">DB_ENV->lock_detect()</a> function, or specify that - Berkeley DB run the deadlock detector internally whenever there is a - conflict over a lock (see <a href="../api_reference/C/envset_lk_detect.html" class="olink">DB_ENV->set_lk_detect()</a> for more information). - The following code fragment does the latter: -</p> + <p> + The first component of the infrastructure, + <span class="emphasis"><em>deadlock detection</em></span>, 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. + </p> + <p> + 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. + </p> + <p> + 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 <a class="link" href="program_errorret.html#program_errorret.DB_LOCK_DEADLOCK">DB_LOCK_DEADLOCK</a> from + whatever Berkeley DB call it was making. Berkeley DB provides the <a href="../api_reference/C/db_deadlock.html" class="olink">db_deadlock</a> utility that + can be used to perform this deadlock detection. Alternatively, + applications can create their own deadlock utility or thread + using the underlying <a href="../api_reference/C/lockdetect.html" class="olink">DB_ENV->lock_detect()</a> function, or specify that + Berkeley DB run the deadlock detector internally whenever + there is a conflict over a lock (see <a href="../api_reference/C/envset_lk_detect.html" class="olink">DB_ENV->set_lk_detect()</a> for + more information). The following code fragment does the + latter: + </p> <pre class="programlisting">void env_open(DB_ENV **dbenvp) { @@ -130,11 +133,12 @@ env_open(DB_ENV **dbenvp) *dbenvp = dbenv; }</pre> - <p> - 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. -</p> + <p> + 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. + </p> </div> <div class="navfooter"> <hr /> @@ -147,7 +151,8 @@ env_open(DB_ENV **dbenvp) <td width="40%" align="right"> <a accesskey="n" href="transapp_checkpoint.html">Next</a></td> </tr> <tr> - <td width="40%" align="left" valign="top">Environment infrastructure </td> + <td width="40%" align="left" valign="top">Environment + infrastructure </td> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> |