[-a e | m | n | o | W | w | y] [-h home] [-L file] [-t sec.usec] </pre>
<p>
The <spanclass="command"><strong>db_deadlock</strong></span> utility traverses the database environment lock
region, and aborts a lock request each time it detects a deadlock or a
lock request that has timed out. By default, in the case of a
deadlock, a random lock request is chosen to be aborted.
</p>
<p>
This utility should be run as a background daemon, or the underlying
Berkeley DB deadlock detection interfaces should be called in some
other way, whenever there are multiple threads or processes accessing
a database and at least one of them is modifying it.
</p>
<p>
The options are as follows:
</p>
<divclass="itemizedlist">
<ultype="disc">
<li>
<p>
<spanclass="bold"><strong>-a</strong></span>
</p>
<p>
When a deadlock is detected, abort the locker:
</p>
<divclass="itemizedlist">
<ultype="circle">
<li>
<p>
<spanclass="bold"><strong>m</strong></span>
</p>
<p>
with the most locks
</p>
</li>
<li>
<p>
<spanclass="bold"><strong>n</strong></span>
</p>
<p>
with the fewest locks
</p>
</li>
<li>
<p>
<spanclass="bold"><strong>o</strong></span>
</p>
<p>
with the oldest locks
</p>
</li>
<li>
<p>
<spanclass="bold"><strong>W</strong></span>
</p>
<p>
with the most write locks
</p>
</li>
<li>
<p>
<spanclass="bold"><strong>w</strong></span>
</p>
<p>
with the fewest write locks
</p>
</li>
<li>
<p>
<spanclass="bold"><strong>y</strong></span>
</p>
<p>
with the youngest locks
</p>
</li>
<li>
<p>
<spanclass="bold"><strong>e</strong></span>
</p>
<p>
When lock or transaction timeouts have been specified, abort any lock
request that has timed out. Note that this option
does not perform the entire deadlock detection
algorithm, but instead only checks for timeouts.
</p>
</li>
</ul>
</div>
</li>
<li>
<p>
<spanclass="bold"><strong>-h</strong></span>
</p>
<p>
Specify a home directory for the database environment; by default, the
current working directory is used.
</p>
</li>
<li>
<p>
<spanclass="bold"><strong>-L</strong></span>
</p>
<p>
Log the execution of the <spanclass="command"><strong>db_deadlock</strong></span> utility to the specified file in
the following format, where <spanclass="emphasis"><em>###</em></span> is the process
ID, and the date is the time the utility was started.
</p>
<preclass="programlisting"> db_deadlock: ### Wed Jun 15 01:23:45 EDT 1995 </pre>
<p>
This file will be removed if the <spanclass="command"><strong>db_deadlock</strong></span>
utility exits gracefully.
</p>
</li>
<li>
<p>
<spanclass="bold"><strong>-t</strong></span>
</p>
<p>
Check the database environment every <spanclass="bold"><strong>sec</strong></span> seconds plus <spanclass="bold"><strong>usec</strong></span> microseconds to see if a process has been
forced to wait for a lock; if one has, review the database environment
lock structures.
</p>
</li>
<li>
<p>
<spanclass="bold"><strong>-V</strong></span>
</p>
<p>
Write the library version number to the standard output, and exit.
</p>
</li>
<li>
<p>
<spanclass="bold"><strong>-v</strong></span>
</p>
<p>
Run in verbose mode, generating messages each time the detector runs.
</p>
</li>
</ul>
</div>
<p>
If the <spanclass="bold"><strong>-t</strong></span> option is not specified,
<spanclass="command"><strong>db_deadlock</strong></span> will run once and exit.
</p>
<p>
The <spanclass="command"><strong>db_deadlock</strong></span> utility uses a Berkeley DB environment (as described
for the <spanclass="bold"><strong>-h</strong></span> option, the environment
variable <spanclass="bold"><strong>DB_HOME</strong></span>, or because the
utility was run in a directory containing a Berkeley DB environment).
In order to avoid environment corruption when using a Berkeley DB
environment, <spanclass="command"><strong>db_deadlock</strong></span> should always be given the chance to detach
from the environment and exit gracefully. To cause <spanclass="command"><strong>db_deadlock</strong></span> to
release all environment resources and exit cleanly, send it an
interrupt signal (SIGINT).
</p>
<p>
The <spanclass="command"><strong>db_deadlock</strong></span> utility does not attempt to create the Berkeley DB
shared memory regions if they do not already exist. The application
which creates the region should be started first, and then, once the
region is created, the <spanclass="command"><strong>db_deadlock</strong></span> utility should be started.
</p>
<p>
The <spanclass="command"><strong>db_deadlock</strong></span> utility exits 0 on success, and >0 if an error
