db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Zigman <john.zig...@gmail.com>
Subject TPC-C (like) benchmarks in derby
Date Mon, 12 Oct 2009 07:17:18 GMT

I am using derby at the moment, although this question relates to
more than specifically this version.

In derbyTesting the org.apache.derbyTesting.system.oe provides a TPC-C
(like) benchmark framework.  Executing the following fragment:

import org.apache.derbyTesting.system.oe.client.MultiThreadSubmitter;
import org.apache.derbyTesting.system.oe.direct.Standard;
import org.apache.derbyTesting.system.oe.client.Submitter;

// ..... <code snipped>
//   initializes connections to derby,
//   initializes OERandom for each submitter
//   initializes an array of two Submitter each a Standard oeprations
//   initializes an array of two Display

public static void run() {
  long  iterationTime = MultiThreadSubmitter.multiRun(submitters, displays,

It is possible with two or more Submitter to yields a deadlock (I have a
vague recollection that this is down to ordering of locks on updates vs
selects but I am not sure) in which case the Submitter performing that
transaction gets an exception from JDBC connection which is unhandled and
terminates the thread.

Is this behaviour correct for TPC-C (like) as it means there is a reasonable
chance that a submitter will never process the right number of transactions.

John Zigman

View raw message