openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Bauer <>
Subject Re: JPAB results
Date Thu, 04 Nov 2010 20:57:19 GMT
Hi Ilan,

Thanks for your post, additional details about JPAB, and your willingness to
try different OpenJPA configurations.  While the performance gap is
concerning, myself and others are especially concerned with the functional
problems you are seeing.  I downloaded the benchmark jar and was able to
reproduce the errors you've documented.  Running the multi-threaded tests
with OpenJPA 2.0.0 on a multi-core system consistently produced duplicate
key exceptions.  I found that this issue is fixed in our 2.0.2-SNAPSHOT and
also in 2.1.0-SNAPSHOT/trunk.  However, the 2.0.2 snapshot runs into another
threading issue, which is caused by OpenJPA's QuerySQLCache.  By disabling
the cache with the property below, I was able to get a clean run with
2.0.2-SNAPSHOT.  Current trunk level code has some fixes in this area and
worked without it.

property-3=<property name="openjpa.jdbc.QuerySQLCache" value="false"/>

I am doing a bit of experimentation with the benchmark in the areas of
connection pooling, data caching, and statement batching.  While OpenJPA has
many performance tuning switches and dials, these three typically have the
most impact.  Some of the other providers have these performance features
enabled by default, so enabling them in OpenJPA helps level the field.

If you have time and wouldn't mind giving OpenJPA another go, you can get
the latest 2.1.0-SNAPSHOT from here:

as of this note the latest snapshot is

This snapshot has connection pooling included and enabled by default.  If
you'd like, you can enable basic, un-tuned, statement batching and data
caching with these properties.

property-3=<property name="openjpa.DataCache" value="true"/>
property-4=<property name="openjpa.jdbc.DBDictionary"

I and I'm sure others others would be interested in the result.  If I come
up with a better set of basic tuning parameters, I'll pass them along.
Others, please feel free to do the same.


On Wed, Nov 3, 2010 at 11:24 AM, Ilan Kirsh <> wrote:

> Hi all,
> I am the author of the JPAB benchmark .
> As Rick wrote - this is indeed an out of the box benchmark. Default
> configuration was used for all the tested products.
> I read with interest what you said about connection pooling. I am keen to
> try this but I wonder whether it will really make a difference because the
> tests do not use short term database connections, and anyway, the time of
> connecting to the database is excluded from the time measurement.
> But probably there are other things that can be done to improve
> performance.
> I'd like to run the tests again with optimized OpenJPA configuration but
> for
> this I will need some help from OpenJPA experts.
> Regarding test failures - I have used standard JPA for the tests. I am
> obviously keen to fix up any problems which are my errors, though, so I'd
> be
> very happy for details I have got incorrect to be pointed out and fixed.
> However, please notice that the same tests that failed with OpenJPA passes
> with other combinations such as Hibernate/MySQL. Therefore, this could
> really be a problem with the OpenJPA processing, as Kevin wrote. I think
> that these tests indicate at least some issues that might have to be fixed
> in OpenJPA.
> Finally, I'd like to address any concerns that the tests are specifically
> designed to make ObjectDB  look best. The tests
> are
> very simple and include only standard JPA operations on simple object
> models. It is open source - does anyone see anything that is biased towards
> ObjectDB performance?  Actually, the performance gap could be even larger
> if
> the object model would be more complex. It is true, however, as explained
> on
>, that when the bottleneck is disk
> activity or network overhead - performance gaps are expected to be much
> lower.
> Best regards,
> Ilan Kirsh
> --
> View this message in context:
> Sent from the OpenJPA Users mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message