openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Georgi Naplatanov <>
Subject Re: JPAB results
Date Fri, 05 Nov 2010 09:20:56 GMT
Hi Ilan.

Do not forget to enable statement pooling in database connection pool 
configuration, if it is not enabled by default.

Best regards

Jeremy Bauer wrote:
> 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"
> value="batchLimit=100"/>
> 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.
> -Jeremy
> 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

View raw message