You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by John Zigman <jo...@gmail.com> on 2009/10/12 09:17:18 UTC

TPC-C (like) benchmarks in derby

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