db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Cable <larry_ca...@yahoo.com>
Subject RESEND: possible resource leak in either Derby DRDA or IBM DB2 Universal JDBC Driver
Date Thu, 13 Jan 2005 23:53:17 GMT
<I'm re-posting; as I did'nt see it make it to the lists>

I recently completed some benchmarking exercises (comparing O.R mapping
technologies) using Derby and the IBM DB2 Universal JDBC
driver (v10?).

The micro benchmark was primarily intended to compare the costs of
various O.R mapping technologies such as Hiberate and JDO vs a
baseline JDBC implementation. So the focus was not DB performance
(but OR mapping performance), *however* the tests did show an alarming 
and inexplicable performance issue with Derby and the DB2 JDBC driver.

The benchmarks were run on an Athlon XP 2400+ system running Fedora
core 1 and JDK 1.4.2_04, using the x86 architecture TSC to obtain
clock speed granularity timings.

When the benchmark was run against Derby in embedded mode, it displayed
(as expected) an approximately constant time for each benchmark
operation (approximately 0.85 millisecs per select/update).

I then ran the ubenchmark with the DB2 JDBC driver in the following 
client/server configurations; in the same JVM as the client, in
a different JVM on the same machine, and on a different machine.

In each case the ubenchmark displayed a near linear increase in cost
(time) per iteration; the minimum being 7.15 mills and the max being
22.96 millis (that's 0.3162ms per run, or 3.1usecs per operation)

The ubenchmark is approximately as follows:

open db connection;
create table pojo (id int not null primary key, int0 int);

for (50x) {
    insert pojo values (0, 0);

    for (1000x) {
        select * from pojo where id = 0 for update;
        update pojo set int0=int0+1 where id=0;

    delete pojo where id=0;

close db connection;

I also ran the same configurations using C-JDBC (using Derby embedded
in a C-JDBC controller) and saw no such linear growth in access time
with an average (constant) time of 8.33ms (min: 7.86, max 10.16)

Although I cannot (yet) identify where the problem is, I believe there
must be some problem in either the DB2 client or the derby server DRDA
implementation ...

anyone got any ideas/comments?

- Larry Cable

Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 

View raw message