1<?xml version="1.0" encoding="UTF-8" standalone="no"?> 2<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 3<html xmlns="http://www.w3.org/1999/xhtml"> 4 <head> 5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 6 <title>Deadlock detection</title> 7 <link rel="stylesheet" href="gettingStarted.css" type="text/css" /> 8 <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /> 9 <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" /> 10 <link rel="up" href="transapp.html" title="Chapter 11. Berkeley DB Transactional Data Store Applications" /> 11 <link rel="prev" href="transapp_admin.html" title="Environment infrastructure" /> 12 <link rel="next" href="transapp_checkpoint.html" title="Checkpoints" /> 13 </head> 14 <body> 15 <div class="navheader"> 16 <table width="100%" summary="Navigation header"> 17 <tr> 18 <th colspan="3" align="center">Deadlock detection</th> 19 </tr> 20 <tr> 21 <td width="20%" align="left"><a accesskey="p" href="transapp_admin.html">Prev</a> </td> 22 <th width="60%" align="center">Chapter 11. 23 Berkeley DB Transactional Data Store Applications 24 </th> 25 <td width="20%" align="right"> <a accesskey="n" href="transapp_checkpoint.html">Next</a></td> 26 </tr> 27 </table> 28 <hr /> 29 </div> 30 <div class="sect1" lang="en" xml:lang="en"> 31 <div class="titlepage"> 32 <div> 33 <div> 34 <h2 class="title" style="clear: both"><a id="transapp_deadlock"></a>Deadlock detection</h2> 35 </div> 36 </div> 37 </div> 38 <p> 39 The first component of the infrastructure, 40 <span class="emphasis"><em>deadlock detection</em></span>, is not so much a 41 requirement specific to transaction-protected applications, but instead 42 is necessary for almost all applications in which more than a single 43 thread of control will be accessing the database at one time. Even 44 when Berkeley DB automatically handles database locking, it is normally 45 possible for deadlock to occur. Because the underlying database access 46 methods may update multiple pages during a single Berkeley DB API call, 47 deadlock is possible even when threads of control are making only 48 single update calls into the database. The exception to this rule is 49 when all the threads of control accessing the database are read-only or 50 when the Berkeley DB Concurrent Data Store product is used; the 51 Berkeley DB Concurrent Data Store product guarantees deadlock-free 52 operation at the expense of reduced concurrency. 53</p> 54 <p> 55 When the deadlock occurs, two (or more) threads of control each request 56 additional locks that can never be granted because one of the threads 57 of control waiting holds the requested resource. For example, consider 58 two processes: A and B. Let's say that A obtains a write lock on item 59 X, and B obtains a write lock on item Y. Then, A requests a lock on Y, 60 and B requests a lock on X. A will wait until resource Y becomes 61 available and B will wait until resource X becomes available. 62 Unfortunately, because both A and B are waiting, neither will release 63 the locks they hold and neither will ever obtain the resource on which 64 it is waiting. For another example, consider two transactions, A and 65 B, each of which may want to modify item X. Assume that transaction A 66 obtains a read lock on X and confirms that a modification is needed. 67 Then it is descheduled and the thread containing transaction B runs. 68 At that time, transaction B obtains a read lock on X and confirms that 69 it also wants to make a modification. Both transactions A and B will 70 block when they attempt to upgrade their read locks to write locks 71 because the other already holds a read lock. This is a deadlock. 72 Transaction A cannot make forward progress until Transaction B releases 73 its read lock on X, but Transaction B cannot make forward progress 74 until Transaction A releases its read lock on X. 75</p> 76 <p> 77 In order to detect that deadlock has happened, a separate process or 78 thread must review the locks currently held in the database. If 79 deadlock has occurred, a victim must be selected, and that victim will 80 then return the error 81 <a class="link" href="program_errorret.html#program_errorret.DB_LOCK_DEADLOCK">DB_LOCK_DEADLOCK</a> 82 from whatever Berkeley DB call it was making. Berkeley DB provides the 83 <a href="../api_reference/C/db_deadlock.html" class="olink">db_deadlock utility</a> that can be used to perform this deadlock detection. 84 Alternatively, applications can create their own deadlock utility or 85 thread using the underlying <a href="../api_reference/C/lockdetect.html" class="olink">DB_ENV->lock_detect()</a> function, or specify that 86 Berkeley DB run the deadlock detector internally whenever there is a 87 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). 88 The following code fragment does the latter: 89</p> 90 <pre class="programlisting">void 91env_open(DB_ENV **dbenvp) 92{ 93 DB_ENV *dbenv; 94 int ret; 95 96 /* Create the environment handle. */ 97 if ((ret = db_env_create(&dbenv, 0)) != 0) { 98 fprintf(stderr, 99 "txnapp: db_env_create: %s\n", db_strerror(ret)); 100 exit (1); 101 } 102 103 /* Set up error handling. */ 104 dbenv->set_errpfx(dbenv, "txnapp"); 105 dbenv->set_errfile(dbenv, stderr); 106 107<span class="bold"><strong> /* Do deadlock detection internally. */ 108 if ((ret = dbenv->set_lk_detect(dbenv, DB_LOCK_DEFAULT)) != 0) { 109 dbenv->err(dbenv, ret, "set_lk_detect: DB_LOCK_DEFAULT"); 110 exit (1); 111 }</strong></span> 112 113 /* 114 * Open a transactional environment: 115 * create if it doesn't exist 116 * free-threaded handle 117 * run recovery 118 * read/write owner only 119 */ 120 if ((ret = dbenv->open(dbenv, ENV_DIRECTORY, 121 DB_CREATE | DB_INIT_LOCK | DB_INIT_LOG | 122 DB_INIT_MPOOL | DB_INIT_TXN | DB_RECOVER | DB_THREAD, 123 S_IRUSR | S_IWUSR)) != 0) { 124 dbenv->err(dbenv, ret, "dbenv->open: %s", ENV_DIRECTORY); 125 exit (1); 126 } 127 128 *dbenvp = dbenv; 129}</pre> 130 <p> 131 Deciding how often to run the deadlock detector and which of the 132 deadlocked transactions will be forced to abort when the deadlock is 133 detected is a common tuning parameter for Berkeley DB applications. 134</p> 135 </div> 136 <div class="navfooter"> 137 <hr /> 138 <table width="100%" summary="Navigation footer"> 139 <tr> 140 <td width="40%" align="left"><a accesskey="p" href="transapp_admin.html">Prev</a> </td> 141 <td width="20%" align="center"> 142 <a accesskey="u" href="transapp.html">Up</a> 143 </td> 144 <td width="40%" align="right"> <a accesskey="n" href="transapp_checkpoint.html">Next</a></td> 145 </tr> 146 <tr> 147 <td width="40%" align="left" valign="top">Environment infrastructure </td> 148 <td width="20%" align="center"> 149 <a accesskey="h" href="index.html">Home</a> 150 </td> 151 <td width="40%" align="right" valign="top"> Checkpoints</td> 152 </tr> 153 </table> 154 </div> 155 </body> 156</html> 157