mirror of
https://github.com/berkeleydb/libdb.git
synced 2024-11-17 01:26:25 +00:00
621 lines
26 KiB
HTML
621 lines
26 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
|||
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|||
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|||
|
<head>
|
|||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
|||
|
<title>The Locking Subsystem</title>
|
|||
|
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
|
|||
|
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
|
|||
|
<link rel="start" href="index.html" title="Getting Started with Berkeley DB Transaction Processing" />
|
|||
|
<link rel="up" href="txnconcurrency.html" title="Chapter 4. Concurrency" />
|
|||
|
<link rel="prev" href="blocking_deadlocks.html" title="Locks, Blocks, and Deadlocks" />
|
|||
|
<link rel="next" href="isolation.html" title="Isolation" />
|
|||
|
</head>
|
|||
|
<body>
|
|||
|
<div xmlns="" class="navheader">
|
|||
|
<div class="libver">
|
|||
|
<p>Library Version 11.2.5.2</p>
|
|||
|
</div>
|
|||
|
<table width="100%" summary="Navigation header">
|
|||
|
<tr>
|
|||
|
<th colspan="3" align="center">The Locking Subsystem</th>
|
|||
|
</tr>
|
|||
|
<tr>
|
|||
|
<td width="20%" align="left"><a accesskey="p" href="blocking_deadlocks.html">Prev</a> </td>
|
|||
|
<th width="60%" align="center">Chapter 4. Concurrency</th>
|
|||
|
<td width="20%" align="right"> <a accesskey="n" href="isolation.html">Next</a></td>
|
|||
|
</tr>
|
|||
|
</table>
|
|||
|
<hr />
|
|||
|
</div>
|
|||
|
<div class="sect1" lang="en" xml:lang="en">
|
|||
|
<div class="titlepage">
|
|||
|
<div>
|
|||
|
<div>
|
|||
|
<h2 class="title" style="clear: both"><a id="lockingsubsystem"></a>The Locking Subsystem</h2>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<div class="toc">
|
|||
|
<dl>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="lockingsubsystem.html#configuringlock">Configuring the Locking Subsystem</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="lockingsubsystem.html#configdeadlkdetect">Configuring Deadlock Detection</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="lockingsubsystem.html#deadlockresolve">Resolving Deadlocks</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="lockingsubsystem.html#setpriority">Setting Transaction Priorities</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
</dl>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
In order to allow concurrent operations, DB provides the locking
|
|||
|
subsystem. This subsystem provides inter- and intra- process
|
|||
|
concurrency mechanisms. It is extensively used by DB concurrent
|
|||
|
applications, but it can also be generally used for non-DB
|
|||
|
resources.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
This section describes the locking subsystem as it is used to
|
|||
|
protect DB resources. In particular, issues on configuration are
|
|||
|
examined here. For information on using the locking subsystem to
|
|||
|
manage non-DB resources, see the
|
|||
|
<em class="citetitle">Berkeley DB Programmer's Reference Guide</em>.
|
|||
|
</p>
|
|||
|
<div class="sect2" lang="en" xml:lang="en">
|
|||
|
<div class="titlepage">
|
|||
|
<div>
|
|||
|
<div>
|
|||
|
<h3 class="title"><a id="configuringlock"></a>Configuring the Locking Subsystem</h3>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
You initialize the locking subsystem by specifying
|
|||
|
<span>
|
|||
|
<code class="literal">DB_INIT_LOCK</code> to the
|
|||
|
|
|||
|
<code class="methodname">DbEnv::open()</code>
|
|||
|
method.
|
|||
|
</span>
|
|||
|
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
Before opening your environment, you can configure various
|
|||
|
values for your locking subsystem. Note that these
|
|||
|
limits can only be configured before the environment is
|
|||
|
opened. Also, these methods configure the entire environment,
|
|||
|
not just a specific environment handle.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
Finally, each bullet below identifies the
|
|||
|
<code class="filename">DB_CONFIG</code> file parameter that can be used
|
|||
|
to specify the specific locking limit. If used, these
|
|||
|
<code class="filename">DB_CONFIG</code> file parameters override any
|
|||
|
value that you might specify using the environment handle.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
The limits that you can configure are as follows:
|
|||
|
</p>
|
|||
|
<div class="itemizedlist">
|
|||
|
<ul type="disc">
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
The number of lockers supported by the environment.
|
|||
|
This value is used by the environment when it is
|
|||
|
opened to estimate the amount of space that it
|
|||
|
should allocate for various internal data
|
|||
|
structures. By default, 1,000 lockers are
|
|||
|
supported.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
To configure this value, use the
|
|||
|
|
|||
|
<span>
|
|||
|
|
|||
|
<code class="methodname">DbEnv::set_memory_init()</code>
|
|||
|
method to configure the <code class="literal">DB_MEM_LOCKER</code> structure.
|
|||
|
</span>
|
|||
|
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
As an alternative to this method, you can configure this
|
|||
|
value using the <code class="filename">DB_CONFIG</code> file's
|
|||
|
<code class="literal">set_lk_max_lockers</code> parameter.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
The number of locks supported by the environment.
|
|||
|
By default, 1,000 locks are supported.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
To configure this value, use the
|
|||
|
<span>
|
|||
|
|
|||
|
<code class="methodname">DbEnv::set_memory_init()</code>
|
|||
|
method to configure the <code class="literal">DB_MEM_LOCK</code> structure.
|
|||
|
</span>
|
|||
|
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
As an alternative to this method, you can configure this
|
|||
|
value using the <code class="filename">DB_CONFIG</code> file's
|
|||
|
<code class="literal">set_lk_max_locks</code> parameter.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
The number of locked objects supported by the
|
|||
|
environment. By default, 1,000 objects can be
|
|||
|
locked.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
To configure this value, use the
|
|||
|
<span>
|
|||
|
|
|||
|
<code class="methodname">DbEnv::set_memory_init()</code>
|
|||
|
method to configure the <code class="literal">DB_MEM_LOCKOBJECT</code> structure.
|
|||
|
</span>
|
|||
|
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
As an alternative to this method, you can configure this
|
|||
|
value using the <code class="filename">DB_CONFIG</code> file's
|
|||
|
<code class="literal">set_lk_max_objects</code> parameter.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
For a definition of lockers, locks, and locked objects, see
|
|||
|
<a class="xref" href="blocking_deadlocks.html#lockresources" title="Lock Resources">Lock Resources</a>.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
For example, to configure the number of locks that your
|
|||
|
environment can use:
|
|||
|
</p>
|
|||
|
<pre class="programlisting">#include "db_cxx.h"
|
|||
|
|
|||
|
...
|
|||
|
|
|||
|
int main(void)
|
|||
|
{
|
|||
|
u_int32_t env_flags = DB_CREATE | // If the environment does not
|
|||
|
// exist, create it.
|
|||
|
DB_INIT_LOCK | // Initialize locking
|
|||
|
DB_INIT_LOG | // Initialize logging
|
|||
|
DB_INIT_MPOOL | // Initialize the cache
|
|||
|
DB_THREAD | // Free-thread the env handle.
|
|||
|
DB_INIT_TXN; // Initialize transactions
|
|||
|
|
|||
|
std::string envHome("/export1/testEnv");
|
|||
|
DbEnv myEnv(0);
|
|||
|
|
|||
|
try {
|
|||
|
|
|||
|
// Configure max locks
|
|||
|
myEnv.set_lk_max_locks(5000);
|
|||
|
myEnv.set_memory_init(DB_MEM_LOCK, 5000);
|
|||
|
|
|||
|
myEnv.open(envHome.c_str(), env_flags, 0);
|
|||
|
|
|||
|
} catch(DbException &e) {
|
|||
|
std::cerr << "Error opening database environment: "
|
|||
|
<< envHome << std::endl;
|
|||
|
std::cerr << e.what() << std::endl;
|
|||
|
return (EXIT_FAILURE);
|
|||
|
}
|
|||
|
|
|||
|
try {
|
|||
|
myEnv.close(0);
|
|||
|
} catch(DbException &e) {
|
|||
|
std::cerr << "Error closing database environment: "
|
|||
|
<< envHome << std::endl;
|
|||
|
std::cerr << e.what() << std::endl;
|
|||
|
return (EXIT_FAILURE);
|
|||
|
}
|
|||
|
|
|||
|
return (EXIT_SUCCESS);
|
|||
|
} </pre>
|
|||
|
</div>
|
|||
|
<div class="sect2" lang="en" xml:lang="en">
|
|||
|
<div class="titlepage">
|
|||
|
<div>
|
|||
|
<div>
|
|||
|
<h3 class="title"><a id="configdeadlkdetect"></a>Configuring Deadlock Detection</h3>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
In order for DB to know that a deadlock has occurred,
|
|||
|
some mechanism must be used to perform deadlock
|
|||
|
detection. There are three ways that deadlock detection can
|
|||
|
occur:
|
|||
|
</p>
|
|||
|
<div class="orderedlist">
|
|||
|
<ol type="1">
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
Allow DB to internally detect deadlocks as they
|
|||
|
occur.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
To do this, you use
|
|||
|
|
|||
|
<span><code class="methodname">DbEnv::set_lk_detect()</code>.</span>
|
|||
|
|
|||
|
This method causes DB to walk its internal lock table
|
|||
|
looking for a deadlock whenever a lock request
|
|||
|
is blocked. This method also identifies how DB decides which lock
|
|||
|
requests are rejected when deadlocks are detected. For example,
|
|||
|
DB can decide to reject the lock request for the transaction
|
|||
|
that has the most number of locks, the least number of locks,
|
|||
|
holds the oldest lock, holds the most number of write locks, and
|
|||
|
so forth (see the API reference documentation for a complete
|
|||
|
list of the lock detection policies).
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
You can call this method at any time during your application's
|
|||
|
lifetime, but typically it is used before you open your environment.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
Note that how you want DB to decide which thread of control should break a deadlock is
|
|||
|
extremely dependent on the nature of your application. It is not unusual for some performance
|
|||
|
testing to be required in order to make this determination. That said, a transaction that is
|
|||
|
holding the most number of locks is usually indicative of the transaction that has performed
|
|||
|
the most amount of work. Frequently you will not want a transaction that has performed a lot of
|
|||
|
work to abandon its efforts and start all over again. It is not therefore uncommon for
|
|||
|
application developers to initially select the transaction with the <span class="emphasis"><em>minimum</em></span>
|
|||
|
number of write locks to break the deadlock.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
Using this mechanism for deadlock detection means
|
|||
|
that your application will never have to wait on a
|
|||
|
lock before discovering that a deadlock has
|
|||
|
occurred. However, walking the lock table every
|
|||
|
time a lock request is blocked can be expensive
|
|||
|
from a performance perspective.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
Use a dedicated thread or external process to perform
|
|||
|
deadlock detection. Note that this thread must be
|
|||
|
performing no other database operations beyond deadlock
|
|||
|
detection.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
To externally perform lock detection, you can use
|
|||
|
either the
|
|||
|
|
|||
|
<code class="methodname">DbEnv::lock_detect()</code>
|
|||
|
|
|||
|
method, or use the
|
|||
|
<span class="command"><strong>db_deadlock</strong></span> command line
|
|||
|
utility. This method (or command) causes DB to walk the
|
|||
|
lock table looking for deadlocks.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
Note that like
|
|||
|
|
|||
|
<span><code class="methodname">DbEnv::set_lk_detect()</code>,</span>
|
|||
|
|
|||
|
you also use this method (or command line utility)
|
|||
|
to identify which lock requests are rejected in the
|
|||
|
event that a deadlock is detected.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
Applications that perform deadlock detection in
|
|||
|
this way typically run deadlock detection between every few
|
|||
|
seconds and a minute. This means that your
|
|||
|
application may have to wait to be notified of a
|
|||
|
deadlock, but you also save the overhead of walking
|
|||
|
the lock table every time a lock request is blocked.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
Lock timeouts.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
You can configure your locking subsystem such that
|
|||
|
it times out any lock that is not released within a
|
|||
|
specified amount of time. To do this, use the
|
|||
|
|
|||
|
<span><code class="methodname">DbEnv::set_timeout()</code></span>
|
|||
|
|
|||
|
method.
|
|||
|
Note that lock timeouts are only checked when a
|
|||
|
lock request is blocked or when deadlock
|
|||
|
detection is otherwise performed. Therefore, a lock can have timed out and still be held for
|
|||
|
some length of time until DB has a reason to examine its locking tables.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
Be aware that extremely long-lived transactions, or
|
|||
|
operations that hold locks for a long time, may be
|
|||
|
inappropriately timed out before the transaction or
|
|||
|
operation has a chance to complete. You should
|
|||
|
therefore use this mechanism only if you know your
|
|||
|
application will hold locks for very short periods
|
|||
|
of time.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
</ol>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
For example, to configure your application such that DB
|
|||
|
checks the lock table for deadlocks every time a lock
|
|||
|
request is blocked:
|
|||
|
</p>
|
|||
|
<pre class="programlisting">#include "db_cxx.h"
|
|||
|
|
|||
|
...
|
|||
|
|
|||
|
int main(void)
|
|||
|
{
|
|||
|
u_int32_t env_flags = DB_CREATE | // If the environment does not
|
|||
|
// exist, create it.
|
|||
|
DB_INIT_LOCK | // Initialize locking
|
|||
|
DB_INIT_LOG | // Initialize logging
|
|||
|
DB_INIT_MPOOL | // Initialize the cache
|
|||
|
DB_THREAD | // Free-thread the env handle
|
|||
|
DB_INIT_TXN; // Initialize transactions
|
|||
|
|
|||
|
std::string envHome("/export1/testEnv");
|
|||
|
DbEnv myEnv(0);
|
|||
|
|
|||
|
try {
|
|||
|
|
|||
|
// Configure db to perform deadlock detection internally, and to
|
|||
|
// choose the transaction that has performed the least amount
|
|||
|
// of writing to break the deadlock in the event that one
|
|||
|
// is detected.
|
|||
|
myEnv.set_lk_detect(DB_LOCK_MINWRITE);
|
|||
|
myEnv.open(envHome.c_str(), env_flags, 0);
|
|||
|
|
|||
|
// From here, you open your databases, proceed with your
|
|||
|
// database operations, and respond to deadlocks as
|
|||
|
// is normal (omitted for brevity).
|
|||
|
|
|||
|
|
|||
|
...</pre>
|
|||
|
<p>
|
|||
|
Finally, the following command line call causes
|
|||
|
deadlock detection to be run against the
|
|||
|
environment contained in <code class="literal">/export/dbenv</code>. The
|
|||
|
transaction with the youngest lock is chosen to break the
|
|||
|
deadlock:
|
|||
|
</p>
|
|||
|
<pre class="programlisting">> /usr/local/db_install/bin/db_deadlock -h /export/dbenv -a y</pre>
|
|||
|
<p>
|
|||
|
For more information, see the
|
|||
|
<a class="ulink" href="http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/db_deadlock.html" target="_top">
|
|||
|
<code class="literal">db_deadlock</code> reference documentation.
|
|||
|
</a>
|
|||
|
</p>
|
|||
|
</div>
|
|||
|
<div class="sect2" lang="en" xml:lang="en">
|
|||
|
<div class="titlepage">
|
|||
|
<div>
|
|||
|
<div>
|
|||
|
<h3 class="title"><a id="deadlockresolve"></a>Resolving Deadlocks</h3>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
When DB determines that a deadlock has occurred, it will
|
|||
|
select a thread of control to resolve the deadlock and then
|
|||
|
|
|||
|
<span>
|
|||
|
throws <code class="literal">DbDeadlockException</code> in that
|
|||
|
thread.
|
|||
|
</span>
|
|||
|
|
|||
|
|
|||
|
If a deadlock is detected, the thread must:
|
|||
|
</p>
|
|||
|
<div class="orderedlist">
|
|||
|
<ol type="1">
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
Cease all read and write operations.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
Close all open cursors.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
Abort the transaction.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
Optionally retry the operation. If your application
|
|||
|
retries deadlocked operations, the new attempt must
|
|||
|
be made using a new transaction.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
</ol>
|
|||
|
</div>
|
|||
|
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
|||
|
<h3 class="title">Note</h3>
|
|||
|
<p>
|
|||
|
If a thread has deadlocked, it may not make any
|
|||
|
additional database calls using the handle that has
|
|||
|
deadlocked.
|
|||
|
</p>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
For example:
|
|||
|
</p>
|
|||
|
<pre class="programlisting">// retry_count is a counter used to identify how many times
|
|||
|
// we've retried this operation. To avoid the potential for
|
|||
|
// endless looping, we won't retry more than MAX_DEADLOCK_RETRIES
|
|||
|
// times.
|
|||
|
|
|||
|
// txn is a transaction handle.
|
|||
|
// key and data are DBT handles. Their usage is not shown here.
|
|||
|
while (retry_count < MAX_DEADLOCK_RETRIES) {
|
|||
|
try {
|
|||
|
envp->txn_begin(NULL, txn, 0);
|
|||
|
dbp->put(txn, &key, &data, 0);
|
|||
|
txn->commit(0);
|
|||
|
return (EXIT_SUCCESS);
|
|||
|
} catch (DbDeadlockException &de) {
|
|||
|
try {
|
|||
|
// Abort the transaction and increment the
|
|||
|
// retry counter
|
|||
|
txn->abort();
|
|||
|
retry_count++;
|
|||
|
// If we've retried too many times, log it and exit
|
|||
|
if (retry_count >= MAX_DEADLOCK_RETRIES) {
|
|||
|
envp->errx("Exceeded retry limit. Giving up.");
|
|||
|
return (EXIT_FAILURE);
|
|||
|
}
|
|||
|
} catch (DbException &ae) {
|
|||
|
envp->err(ae.get_errno(), "txn abort failed.");
|
|||
|
return (EXIT_FAILURE);
|
|||
|
}
|
|||
|
} catch (DbException &e) {
|
|||
|
try {
|
|||
|
// For a generic error, log it and abort.
|
|||
|
envp->err(e.get_errno(), "Error putting data.");
|
|||
|
txn->abort();
|
|||
|
} catch (DbException &ae) {
|
|||
|
envp->err(ae.get_errno(), "txn abort failed.");
|
|||
|
return (EXIT_FAILURE);
|
|||
|
}
|
|||
|
}
|
|||
|
} </pre>
|
|||
|
</div>
|
|||
|
<div class="sect2" lang="en" xml:lang="en">
|
|||
|
<div class="titlepage">
|
|||
|
<div>
|
|||
|
<div>
|
|||
|
<h3 class="title"><a id="setpriority"></a>Setting Transaction Priorities</h3>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
Normally when a thread of control must be selected to
|
|||
|
resolve a deadlock, DB decides which thread will
|
|||
|
perform the resolution; you have no way of knowing in
|
|||
|
advance which thread will be selected to resolve the
|
|||
|
deadlock.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
However, there may be situations where you know it is
|
|||
|
better for one thread to resolve a deadlock over another
|
|||
|
thread. As an example, if you have a background thread
|
|||
|
running data management activities, and another thread
|
|||
|
responding to user requests, you might want deadlock
|
|||
|
resolution to occur in the background thread because you
|
|||
|
can better afford the throughput costs there. Under these
|
|||
|
circumstances, you can identify which thread of control
|
|||
|
will be selected for resolved deadlocks by setting a
|
|||
|
transaction priorities.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
When two transactions are deadlocked, DB will abort the
|
|||
|
transaction with the lowest priority. By default, every
|
|||
|
transaction is given a priority of 100. However, you can
|
|||
|
set a different priority on a transaction-by-transaction
|
|||
|
basis by using the
|
|||
|
|
|||
|
<code class="methodname">DbTxn::set_priority()</code>
|
|||
|
|
|||
|
method.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
When two or more transactions are tied for the lowest
|
|||
|
priority, the tie is broken based on the policy provided to
|
|||
|
<span>
|
|||
|
the
|
|||
|
|
|||
|
<code class="methodname">DbEnv::lock_detect()</code>
|
|||
|
method's <code class="literal">atype</code> parameter.
|
|||
|
</span>
|
|||
|
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
A transaction's priority can be changed at any time after
|
|||
|
the transaction handle has been created and before the
|
|||
|
transaction has been resolved (committed or aborted).
|
|||
|
For example:
|
|||
|
</p>
|
|||
|
<pre class="programlisting">#include "db_cxx.h"
|
|||
|
|
|||
|
...
|
|||
|
|
|||
|
int main(void)
|
|||
|
{
|
|||
|
...
|
|||
|
|
|||
|
try {
|
|||
|
|
|||
|
...
|
|||
|
// Database and environment open omitted for brevity.
|
|||
|
...
|
|||
|
DbTxn *txn = NULL;
|
|||
|
myEnv.txn_begin(NULL, &txn, 0);
|
|||
|
<strong class="userinput"><code>txn->set_priority(200);</code></strong>
|
|||
|
|
|||
|
try {
|
|||
|
db->put(txn, &key, &data, 0);
|
|||
|
txn->commit(0);
|
|||
|
} catch (DbException &e) {
|
|||
|
std::cerr << "Error in transaction: "
|
|||
|
<< e.what() << std::endl;
|
|||
|
txn->abort();
|
|||
|
}
|
|||
|
|
|||
|
} catch(DbException &e) {
|
|||
|
std::cerr << "Error opening database and environment: "
|
|||
|
<< file_name << ", "
|
|||
|
<< envHome << std::endl;
|
|||
|
std::cerr << e.what() << std::endl;
|
|||
|
}
|
|||
|
|
|||
|
...
|
|||
|
|
|||
|
} </pre>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<div class="navfooter">
|
|||
|
<hr />
|
|||
|
<table width="100%" summary="Navigation footer">
|
|||
|
<tr>
|
|||
|
<td width="40%" align="left"><a accesskey="p" href="blocking_deadlocks.html">Prev</a> </td>
|
|||
|
<td width="20%" align="center">
|
|||
|
<a accesskey="u" href="txnconcurrency.html">Up</a>
|
|||
|
</td>
|
|||
|
<td width="40%" align="right"> <a accesskey="n" href="isolation.html">Next</a></td>
|
|||
|
</tr>
|
|||
|
<tr>
|
|||
|
<td width="40%" align="left" valign="top">Locks, Blocks, and Deadlocks </td>
|
|||
|
<td width="20%" align="center">
|
|||
|
<a accesskey="h" href="index.html">Home</a>
|
|||
|
</td>
|
|||
|
<td width="40%" align="right" valign="top"> Isolation</td>
|
|||
|
</tr>
|
|||
|
</table>
|
|||
|
</div>
|
|||
|
</body>
|
|||
|
</html>
|