mirror of
https://github.com/berkeleydb/je.git
synced 2024-11-15 01:46:24 +00:00
706 lines
28 KiB
HTML
706 lines
28 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>DPL Transaction Example</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, Java Edition Transaction Processing" />
|
|||
|
<link rel="up" href="wrapup.html" title="Chapter 6. Summary and Examples" />
|
|||
|
<link rel="prev" href="txnexample_java.html" title="Base API Transaction Example" />
|
|||
|
</head>
|
|||
|
<body>
|
|||
|
<div xmlns="" class="navheader">
|
|||
|
<div class="libver">
|
|||
|
<p>Library Version 12.2.7.5</p>
|
|||
|
</div>
|
|||
|
<table width="100%" summary="Navigation header">
|
|||
|
<tr>
|
|||
|
<th colspan="3" align="center">DPL Transaction Example</th>
|
|||
|
</tr>
|
|||
|
<tr>
|
|||
|
<td width="20%" align="left"><a accesskey="p" href="txnexample_java.html">Prev</a> </td>
|
|||
|
<th width="60%" align="center">Chapter 6. Summary and Examples</th>
|
|||
|
<td width="20%" align="right"> </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="txnexample_dpl"></a>DPL Transaction Example</h2>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<div class="toc">
|
|||
|
<dl>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="txnexample_dpl.html#txnguideexample_dpl">TxnGuide.java</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="txnexample_dpl.html#payloaddataentity">PayloadDataEntity.java</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
<dt>
|
|||
|
<span class="sect2">
|
|||
|
<a href="txnexample_dpl.html#storewriter">StoreWriter.java</a>
|
|||
|
</span>
|
|||
|
</dt>
|
|||
|
</dl>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
The following Java code provides a fully functional example of a
|
|||
|
multi-threaded transactional JE application using the DPL.
|
|||
|
This example is nearly identical to the example provided in the
|
|||
|
previous section, except that it uses an entity class and entity
|
|||
|
store to manage its data.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
As is the case with the previous examples, this example opens
|
|||
|
an environment and then an entity store. It then creates
|
|||
|
5 threads, each of which writes 500 records to the database.
|
|||
|
The primary key for these writes are based on pre-determined
|
|||
|
integers, while the data is randomly generated data.
|
|||
|
This means that the actual data is arbitrary and therefore uninteresting;
|
|||
|
we picked it only because it requires minimum code to implement and therefore will
|
|||
|
stay out of the way of the main points of this example.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
Each thread writes 10 records under a single transaction
|
|||
|
before committing and writing another 10 (this is repeated 50
|
|||
|
times). At the end of each transaction, but before committing, each
|
|||
|
thread calls a function that uses a cursor to read every record in
|
|||
|
the database. We do this in order to make some points about
|
|||
|
database reads in a transactional environment.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
Of course, each writer thread performs deadlock detection as
|
|||
|
described in this manual. In addition, normal recovery is performed
|
|||
|
when the environment is opened.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
To implement this example, we need three classes:
|
|||
|
</p>
|
|||
|
<div class="itemizedlist">
|
|||
|
<ul type="disc">
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
<code class="literal">TxnGuide.java</code>
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
This is the main class for the application. It performs
|
|||
|
environment and store management, spawns threads, and
|
|||
|
creates the data that is placed in the database. See <a class="xref" href="txnexample_dpl.html#txnguideexample_dpl" title="TxnGuide.java">TxnGuide.java</a> for implementation details.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
<code class="literal">StoreWriter.java</code>
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
This class extends <code class="literal">java.lang.Thread</code>, and
|
|||
|
as such it is our thread implementation. It is responsible
|
|||
|
for actually reading and writing store. It also
|
|||
|
performs all of our transaction management. See <a class="xref" href="txnexample_dpl.html#storewriter" title="StoreWriter.java">StoreWriter.java</a> for
|
|||
|
implementation details.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
<code class="literal">PayloadDataEntity.java</code>
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
This is an entity class used to encapsulate several data
|
|||
|
fields. See <a class="xref" href="txnexample_dpl.html#payloaddataentity" title="PayloadDataEntity.java">PayloadDataEntity.java</a> for
|
|||
|
implementation details.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
</div>
|
|||
|
<div class="sect2" lang="en" xml:lang="en">
|
|||
|
<div class="titlepage">
|
|||
|
<div>
|
|||
|
<div>
|
|||
|
<h3 class="title"><a id="txnguideexample_dpl"></a>TxnGuide.java</h3>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
The main class in our example application is used to open and
|
|||
|
close our environment and store. It also spawns all the
|
|||
|
threads that we need. We start with the normal series
|
|||
|
of Java package and import statements, followed by our class
|
|||
|
declaration:
|
|||
|
</p>
|
|||
|
<pre class="programlisting">// File TxnGuideDPL.java
|
|||
|
|
|||
|
package persist.txn;
|
|||
|
|
|||
|
import com.sleepycat.je.DatabaseConfig;
|
|||
|
import com.sleepycat.je.DatabaseException;
|
|||
|
|
|||
|
import com.sleepycat.je.Environment;
|
|||
|
import com.sleepycat.je.EnvironmentConfig;
|
|||
|
|
|||
|
import com.sleepycat.persist.EntityStore;
|
|||
|
import com.sleepycat.persist.StoreConfig;
|
|||
|
|
|||
|
import java.io.File;
|
|||
|
|
|||
|
public class TxnGuideDPL { </pre>
|
|||
|
<p>
|
|||
|
Next we declare our class' private data members. Mostly these are used
|
|||
|
for constants such as the name of the database that we are opening and
|
|||
|
the number of threads that we are spawning. However, we also declare
|
|||
|
our environment and database handles here.
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> private static String myEnvPath = "./";
|
|||
|
private static String storeName = "exampleStore";
|
|||
|
|
|||
|
// Handles
|
|||
|
private static EntityStore myStore = null;
|
|||
|
private static Environment myEnv = null;
|
|||
|
private static final int NUMTHREADS = 5; </pre>
|
|||
|
<p>
|
|||
|
Next, we implement our <code class="function">usage()</code> method. This
|
|||
|
application optionally accepts a single command line argument which is
|
|||
|
used to identify the environment home directory.
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> private static void usage() {
|
|||
|
System.out.println("TxnGuideDPL [-h <env directory>]");
|
|||
|
System.exit(-1);
|
|||
|
} </pre>
|
|||
|
<p>
|
|||
|
Now we implement our <code class="function">main()</code> method. This method
|
|||
|
simply calls the methods to parse the command line arguments and open
|
|||
|
the environment and store. It also creates and then joins the store writer
|
|||
|
threads.
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> public static void main(String args[]) {
|
|||
|
try {
|
|||
|
// Parse the arguments list
|
|||
|
parseArgs(args);
|
|||
|
// Open the environment and store
|
|||
|
openEnv();
|
|||
|
|
|||
|
// Start the threads
|
|||
|
StoreWriter[] threadArray;
|
|||
|
threadArray = new StoreWriter[NUMTHREADS];
|
|||
|
for (int i = 0; i < NUMTHREADS; i++) {
|
|||
|
threadArray[i] = new StoreWriter(myEnv, myStore);
|
|||
|
threadArray[i].start();
|
|||
|
}
|
|||
|
|
|||
|
for (int i = 0; i < NUMTHREADS; i++) {
|
|||
|
threadArray[i].join();
|
|||
|
}
|
|||
|
} catch (Exception e) {
|
|||
|
System.err.println("TxnGuideDPL: " + e.toString());
|
|||
|
e.printStackTrace();
|
|||
|
} finally {
|
|||
|
closeEnv();
|
|||
|
}
|
|||
|
System.out.println("All done.");
|
|||
|
} </pre>
|
|||
|
<p>
|
|||
|
Next we implement <code class="function">openEnv()</code>. This method is used
|
|||
|
to open the environment and then an entity store in that environment. Along
|
|||
|
the way, we make sure that the transactional subsystem is correctly
|
|||
|
initialized.
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> private static void openEnv() throws DatabaseException {
|
|||
|
System.out.println("opening env and store");
|
|||
|
|
|||
|
// Set up the environment.
|
|||
|
EnvironmentConfig myEnvConfig = new EnvironmentConfig();
|
|||
|
myEnvConfig.setAllowCreate(true);
|
|||
|
myEnvConfig.setTransactional(true);
|
|||
|
// Environment handles are free-threaded by default in JE,
|
|||
|
// so we do not have to do anything to cause the
|
|||
|
// environment handle to be free-threaded.
|
|||
|
|
|||
|
// Set up the entity store
|
|||
|
StoreConfig myStoreConfig = new StoreConfig();
|
|||
|
myStoreConfig.setAllowCreate(true);
|
|||
|
myStoreConfig.setTransactional(true);
|
|||
|
|
|||
|
// Open the environment
|
|||
|
myEnv = new Environment(new File(myEnvPath), // Env home
|
|||
|
myEnvConfig);
|
|||
|
|
|||
|
// Open the store
|
|||
|
myStore = new EntityStore(myEnv, storeName, myStoreConfig);
|
|||
|
} </pre>
|
|||
|
<p>
|
|||
|
Finally, we implement the methods used to close our environment and
|
|||
|
databases, parse the command line arguments, and provide our class
|
|||
|
constructor. This is fairly standard code and it is mostly
|
|||
|
uninteresting from the perspective of this manual. We include it here
|
|||
|
purely for the purpose of completeness.
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> private static void closeEnv() {
|
|||
|
System.out.println("Closing env and store");
|
|||
|
if (myStore != null ) {
|
|||
|
try {
|
|||
|
myStore.close();
|
|||
|
} catch (DatabaseException e) {
|
|||
|
System.err.println("closeEnv: myStore: " +
|
|||
|
e.toString());
|
|||
|
e.printStackTrace();
|
|||
|
}
|
|||
|
}
|
|||
|
|
|||
|
if (myEnv != null ) {
|
|||
|
try {
|
|||
|
myEnv.close();
|
|||
|
} catch (DatabaseException e) {
|
|||
|
System.err.println("closeEnv: " + e.toString());
|
|||
|
e.printStackTrace();
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
|
|||
|
private TxnGuideDPL() {}
|
|||
|
|
|||
|
private static void parseArgs(String args[]) {
|
|||
|
int nArgs = args.length;
|
|||
|
for(int i = 0; i < args.length; ++i) {
|
|||
|
if (args[i].startsWith("-")) {
|
|||
|
switch(args[i].charAt(1)) {
|
|||
|
case 'h':
|
|||
|
if (i < nArgs - 1) {
|
|||
|
myEnvPath = new String(args[++i]);
|
|||
|
}
|
|||
|
break;
|
|||
|
default:
|
|||
|
usage();
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
} </pre>
|
|||
|
</div>
|
|||
|
<div class="sect2" lang="en" xml:lang="en">
|
|||
|
<div class="titlepage">
|
|||
|
<div>
|
|||
|
<div>
|
|||
|
<h3 class="title"><a id="payloaddataentity"></a>PayloadDataEntity.java</h3>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
Before we show the implementation of the store writer thread, we
|
|||
|
need to show the class that we will be placing into the store. This
|
|||
|
class is fairly minimal. It simply allows you to store and retrieve an
|
|||
|
<code class="literal">int</code>, a <code class="literal">String</code>, and a
|
|||
|
<code class="literal">double</code>. The <code class="literal">int</code> is our primary key.
|
|||
|
</p>
|
|||
|
<pre class="programlisting">package persist.txn;
|
|||
|
import com.sleepycat.persist.model.Entity;
|
|||
|
import com.sleepycat.persist.model.PrimaryKey;
|
|||
|
import static com.sleepycat.persist.model.Relationship.*;
|
|||
|
|
|||
|
@Entity
|
|||
|
public class PayloadDataEntity {
|
|||
|
@PrimaryKey
|
|||
|
private int oID;
|
|||
|
|
|||
|
private String threadName;
|
|||
|
|
|||
|
private double doubleData;
|
|||
|
|
|||
|
PayloadDataEntity() {}
|
|||
|
|
|||
|
public double getDoubleData() { return doubleData; }
|
|||
|
public int getID() { return oID; }
|
|||
|
public String getThreadName() { return threadName; }
|
|||
|
|
|||
|
public void setDoubleData(double dd) { doubleData = dd; }
|
|||
|
public void setID(int id) { oID = id; }
|
|||
|
public void setThreadName(String tn) { threadName = tn; }
|
|||
|
|
|||
|
} </pre>
|
|||
|
</div>
|
|||
|
<div class="sect2" lang="en" xml:lang="en">
|
|||
|
<div class="titlepage">
|
|||
|
<div>
|
|||
|
<div>
|
|||
|
<h3 class="title"><a id="storewriter"></a>StoreWriter.java</h3>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
<code class="literal">StoreWriter.java</code> provides the implementation
|
|||
|
for our entity store writer thread. It is responsible for:
|
|||
|
</p>
|
|||
|
<div class="itemizedlist">
|
|||
|
<ul type="disc">
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
All transaction management.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
Responding to deadlock exceptions.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
Providing data to be stored in the entity store.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
Writing the data to the store.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
In order to show off some of the ACID properties provided
|
|||
|
by JE's transactional support,
|
|||
|
<code class="literal">StoreWriter.java</code> does some things in a less
|
|||
|
efficient way than you would probably decide to use in a
|
|||
|
true production application. First, it groups 10 database
|
|||
|
writes together in a single transaction when you could just
|
|||
|
as easily perform one write for each transaction. If you
|
|||
|
did this, you could use auto commit for the individual
|
|||
|
database writes, which means your code would be slightly
|
|||
|
simpler and you would run a <span class="emphasis"><em>much</em></span>
|
|||
|
smaller chance of encountering blocked and deadlocked
|
|||
|
operations. However, by doing things this way, we are able
|
|||
|
to show transactional atomicity, as well as deadlock
|
|||
|
handling.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
To begin, we provide the usual package and import statements, and we declare our class:
|
|||
|
</p>
|
|||
|
<pre class="programlisting">package persist.txn;
|
|||
|
|
|||
|
import com.sleepycat.je.CursorConfig;
|
|||
|
import com.sleepycat.je.DatabaseException;
|
|||
|
import com.sleepycat.je.LockConflictException;
|
|||
|
import com.sleepycat.je.Environment;
|
|||
|
import com.sleepycat.je.Transaction;
|
|||
|
|
|||
|
import com.sleepycat.persist.EntityCursor;
|
|||
|
import com.sleepycat.persist.EntityStore;
|
|||
|
import com.sleepycat.persist.PrimaryIndex;
|
|||
|
|
|||
|
import java.util.Iterator;
|
|||
|
import java.util.Random;
|
|||
|
import java.io.UnsupportedEncodingException;
|
|||
|
|
|||
|
public class StoreWriter extends Thread
|
|||
|
{ </pre>
|
|||
|
<p>
|
|||
|
Next we declare our private data members. Notice that we get handles
|
|||
|
for the environment and the entity store. The random number generator
|
|||
|
that we instantiate is used
|
|||
|
to generate unique data for storage in the database. Finally, the
|
|||
|
<code class="literal">MAX_RETRY</code> variable is used to define how many times
|
|||
|
we will retry a transaction in the face of a deadlock.
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> private EntityStore myStore = null;
|
|||
|
private Environment myEnv = null;
|
|||
|
private PrimaryIndex<Integer,PayloadDataEntity> pdKey;
|
|||
|
private Random generator = new Random();
|
|||
|
private boolean passTxn = false;
|
|||
|
|
|||
|
private static final int MAX_RETRY = 20; </pre>
|
|||
|
<p>
|
|||
|
Next we implement our class constructor. The most interesting thing about our constructor is
|
|||
|
that we use it to obtain our entity class's primary index.
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> // Constructor. Get our handles from here
|
|||
|
StoreWriter(Environment env, EntityStore store)
|
|||
|
|
|||
|
throws DatabaseException {
|
|||
|
myStore = store;
|
|||
|
myEnv = env;
|
|||
|
|
|||
|
// Open the data accessor. This is used to store persistent
|
|||
|
// objects.
|
|||
|
pdKey = myStore.getPrimaryIndex(Integer.class,
|
|||
|
PayloadDataEntity.class);
|
|||
|
} </pre>
|
|||
|
<p>
|
|||
|
Now we implement our thread's <code class="methodname">run()</code> method.
|
|||
|
This is the method that is run when <code class="classname">StoreWriter</code>
|
|||
|
threads are started in the main program (see <a class="xref" href="txnexample_dpl.html#txnguideexample_dpl" title="TxnGuide.java">TxnGuide.java</a>).
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> // Thread method that writes a series of records
|
|||
|
// to the database using transaction protection.
|
|||
|
// Deadlock handling is demonstrated here.
|
|||
|
public void run () { </pre>
|
|||
|
<p>
|
|||
|
The first thing we do is get a <code class="literal">null</code> transaction
|
|||
|
handle before going into our main loop. We also begin the top transaction loop here that causes our application to
|
|||
|
perform 50 transactions.
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> Transaction txn = null;
|
|||
|
|
|||
|
// Perform 50 transactions
|
|||
|
for (int i=0; i<50; i++) { </pre>
|
|||
|
<p>
|
|||
|
Next we declare a <code class="literal">retry</code> variable. This is used to
|
|||
|
determine whether a deadlock should result in our retrying the
|
|||
|
operation. We also declare a <code class="literal">retry_count</code> variable
|
|||
|
that is used to make sure we do not retry a transaction forever in the
|
|||
|
unlikely event that the thread is unable to ever get a necessary lock.
|
|||
|
(The only thing that might cause this is if some other thread dies
|
|||
|
while holding an important lock. This is the only code that we have to
|
|||
|
guard against that because the simplicity of this application makes it
|
|||
|
highly unlikely that it will ever occur.)
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> boolean retry = true;
|
|||
|
int retry_count = 0;
|
|||
|
// while loop is used for deadlock retries
|
|||
|
while (retry) { </pre>
|
|||
|
<p>
|
|||
|
Now we go into the <code class="literal">try</code> block that we use for
|
|||
|
deadlock detection. We also begin our transaction here.
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> // try block used for deadlock detection and
|
|||
|
// general exception handling
|
|||
|
try {
|
|||
|
|
|||
|
// Get a transaction
|
|||
|
txn = myEnv.beginTransaction(null, null); </pre>
|
|||
|
<p>
|
|||
|
Now we write 10 objects under the transaction that we have just begun.
|
|||
|
By combining multiple writes together under a single transaction,
|
|||
|
we increase the likelihood that a deadlock will occur. Normally,
|
|||
|
you want to reduce the potential for a deadlock and in this case
|
|||
|
the way to do that is to perform a single write per transaction. In
|
|||
|
other words, we <span class="emphasis"><em>should</em></span> be using auto commit to
|
|||
|
write to our database for this workload.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
However, we want to show deadlock handling and by performing
|
|||
|
multiple writes per transaction we can actually observe deadlocks
|
|||
|
occurring. We also want to underscore the idea that you can
|
|||
|
combing multiple database operations together in a single atomic
|
|||
|
unit of work. So for our example, we do the (slightly) wrong thing.
|
|||
|
</p>
|
|||
|
<pre class="programlisting">
|
|||
|
|
|||
|
// Write 10 PayloadDataEntity objects to the
|
|||
|
// store for each transaction
|
|||
|
for (int j = 0; j < 10; j++) {
|
|||
|
// Instantiate an object
|
|||
|
PayloadDataEntity pd = new PayloadDataEntity();
|
|||
|
|
|||
|
// Set the Object ID. This is used as the
|
|||
|
// primary key.
|
|||
|
pd.setID(i + j);
|
|||
|
|
|||
|
// The thread name is used as a secondary key, and
|
|||
|
// it is retrieved by this class's getName()
|
|||
|
// method.
|
|||
|
pd.setThreadName(getName());
|
|||
|
|
|||
|
// The last bit of data that we use is a double
|
|||
|
// that we generate randomly. This data is not
|
|||
|
// indexed.
|
|||
|
pd.setDoubleData(generator.nextDouble());
|
|||
|
|
|||
|
// Do the put
|
|||
|
pdKey.put(txn, pd);
|
|||
|
} </pre>
|
|||
|
<p>
|
|||
|
Having completed the inner database write loop, we could simply
|
|||
|
commit the transaction and continue on to the next block of 10
|
|||
|
writes. However, we want to first illustrate a few points about
|
|||
|
transactional processing so instead we call our
|
|||
|
<code class="function">countObjects()</code> method before calling the transaction
|
|||
|
commit. <code class="function">countObjects()</code> uses a cursor to read every
|
|||
|
object in the entity store and return a count of the number of objects
|
|||
|
that it found.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
Because
|
|||
|
<code class="function">countObjects()</code>
|
|||
|
reads every object in the store, if used incorrectly the thread
|
|||
|
will self-deadlock. The writer thread has just written 500 objects
|
|||
|
to the database, but because the transaction used for that write
|
|||
|
has not yet been committed, each of those 500 objects are still
|
|||
|
locked by the thread's transaction. If we then simply run a
|
|||
|
non-transactional cursor over the store from within the same
|
|||
|
thread that has locked those 500 objects, the cursor will
|
|||
|
block when it tries to read one of those transactional
|
|||
|
protected records. The thread immediately stops operation at that
|
|||
|
point while the cursor waits for the read lock it has
|
|||
|
requested. Because that read lock will never be released (the thread
|
|||
|
can never make any forward progress), this represents a
|
|||
|
self-deadlock for the thread.
|
|||
|
</p>
|
|||
|
<p>
|
|||
|
There are three ways to prevent this self-deadlock:
|
|||
|
</p>
|
|||
|
<div class="orderedlist">
|
|||
|
<ol type="1">
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
We can move the call to
|
|||
|
<code class="function">countObjects()</code> to a point after the
|
|||
|
thread's transaction has committed.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
We can allow <code class="function">countObjects()</code> to
|
|||
|
operate under the same transaction as all of the writes
|
|||
|
were performed.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>
|
|||
|
We can reduce our isolation guarantee for the application
|
|||
|
by allowing uncommitted reads.
|
|||
|
</p>
|
|||
|
</li>
|
|||
|
</ol>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
For this example, we choose to use option 3 (uncommitted reads) to avoid
|
|||
|
the deadlock. This means that we have to open our cursor handle
|
|||
|
so that it knows to perform uncommitted reads.
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> // commit
|
|||
|
System.out.println(getName() + " : committing txn : "
|
|||
|
+ i);
|
|||
|
System.out.println(getName() + " : Found " +
|
|||
|
countObjects(txn) + " objects in the store.");</pre>
|
|||
|
<p>
|
|||
|
Having performed this somewhat inelegant counting of the objects in the
|
|||
|
database, we can now commit the transaction.
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> try {
|
|||
|
txn.commit();
|
|||
|
txn = null;
|
|||
|
} catch (DatabaseException e) {
|
|||
|
System.err.println("Error on txn commit: " +
|
|||
|
e.toString());
|
|||
|
}
|
|||
|
retry = false; </pre>
|
|||
|
<p>
|
|||
|
If all goes well with the commit, we are done and we can move on to the
|
|||
|
next batch of 10 objects to add to the store. However, in the event
|
|||
|
of an error, we must handle our exceptions correctly. The first of
|
|||
|
these is a deadlock exception. In the event of a deadlock, we want to
|
|||
|
abort and retry the transaction, provided that we have not already
|
|||
|
exceeded our retry limit for this transaction.
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> } catch (LockConflictException lce) {
|
|||
|
System.out.println("################# " + getName() +
|
|||
|
" : caught deadlock");
|
|||
|
// retry if necessary
|
|||
|
if (retry_count < MAX_RETRY) {
|
|||
|
System.err.println(getName() +
|
|||
|
" : Retrying operation.");
|
|||
|
retry = true;
|
|||
|
retry_count++;
|
|||
|
} else {
|
|||
|
System.err.println(getName() +
|
|||
|
" : out of retries. Giving up.");
|
|||
|
retry = false;
|
|||
|
} </pre>
|
|||
|
<p>
|
|||
|
In the event of a standard, non-specific database exception, we simply
|
|||
|
log the exception and then give up (the transaction is not retried).
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> } catch (DatabaseException e) {
|
|||
|
// abort and don't retry
|
|||
|
retry = false;
|
|||
|
System.err.println(getName() +
|
|||
|
" : caught exception: " + e.toString());
|
|||
|
e.printStackTrace(); </pre>
|
|||
|
<p>
|
|||
|
And, finally, we always abort the transaction if the transaction handle
|
|||
|
is not null. Note that immediately after committing our transaction, we
|
|||
|
set the transaction handle to null to guard against aborting a
|
|||
|
transaction that has already been committed.
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> } finally {
|
|||
|
if (txn != null) {
|
|||
|
try {
|
|||
|
txn.abort();
|
|||
|
} catch (Exception e) {
|
|||
|
System.err.println("Error aborting txn: " +
|
|||
|
e.toString());
|
|||
|
e.printStackTrace();
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
} </pre>
|
|||
|
<p>
|
|||
|
The final piece of our <code class="classname">StoreWriter</code> class is the
|
|||
|
<code class="methodname">countObjects()</code> implementation. Notice how in
|
|||
|
this example we open the cursor such that it performs uncommitted
|
|||
|
reads:
|
|||
|
</p>
|
|||
|
<pre class="programlisting"> // A method that counts every object in the store.
|
|||
|
|
|||
|
private int countObjects(Transaction txn) throws DatabaseException {
|
|||
|
int count = 0;
|
|||
|
|
|||
|
CursorConfig cc = new CursorConfig();
|
|||
|
// This is ignored if the store is not opened with uncommitted read
|
|||
|
// support.
|
|||
|
cc.setReadUncommitted(true);
|
|||
|
EntityCursor<PayloadDataEntity> cursor = pdKey.entities(txn, cc);
|
|||
|
|
|||
|
try {
|
|||
|
for (PayloadDataEntity pdi : cursor) {
|
|||
|
count++;
|
|||
|
}
|
|||
|
} finally {
|
|||
|
if (cursor != null) {
|
|||
|
cursor.close();
|
|||
|
}
|
|||
|
}
|
|||
|
|
|||
|
return count;
|
|||
|
|
|||
|
}
|
|||
|
} </pre>
|
|||
|
</div>
|
|||
|
<p>
|
|||
|
This completes our transactional example. If you would like to
|
|||
|
experiment with this code, you can find the example in the following
|
|||
|
location in your JE distribution:
|
|||
|
</p>
|
|||
|
<pre class="programlisting"><span class="emphasis"><em>JE_HOME</em></span>/examples/persist/txn</pre>
|
|||
|
</div>
|
|||
|
<div class="navfooter">
|
|||
|
<hr />
|
|||
|
<table width="100%" summary="Navigation footer">
|
|||
|
<tr>
|
|||
|
<td width="40%" align="left"><a accesskey="p" href="txnexample_java.html">Prev</a> </td>
|
|||
|
<td width="20%" align="center">
|
|||
|
<a accesskey="u" href="wrapup.html">Up</a>
|
|||
|
</td>
|
|||
|
<td width="40%" align="right"> </td>
|
|||
|
</tr>
|
|||
|
<tr>
|
|||
|
<td width="40%" align="left" valign="top">Base API Transaction Example </td>
|
|||
|
<td width="20%" align="center">
|
|||
|
<a accesskey="h" href="index.html">Home</a>
|
|||
|
</td>
|
|||
|
<td width="40%" align="right" valign="top"> </td>
|
|||
|
</tr>
|
|||
|
</table>
|
|||
|
</div>
|
|||
|
</body>
|
|||
|
</html>
|