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