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
hi

I am using derby 10.5.3.0 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
processor
//   initializes an array of two Display

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

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

Mime
View raw message