openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dick <>
Subject Re: OpenJPA MySQL performance overhead
Date Wed, 14 Jul 2010 15:03:04 GMT

In your JPA test you start a transaction for each find - if you aren't going
to modify the entities there's no real need for a transaction - does
removing the tran help?

We're never going to quite equal JDBC, since OpenJPA will be creating a new
PreparedStatement each time - the prepared statement pool you have on dbcp
should help a lot though.

Also in the JPA case the application is creating 20,000 instances of your
entities - whereas with JDBC you just check the results count (I'm guessing
a bit here). So there's a GC impact with JPA (and there would be with any
ORM). If you were to do more with the data in the JDBC case you should see
the numbers get closer.

Regarding openjpa.Multithreaded, this is useful if you plan to use a single
EntityManager on multiple threads at the same time. This pattern can be
tricky to get right - I'd strongly recommend removing the property and
getting a new EntityManager for each thread (you can use a single
EntityManagerFactory for all threads though).


On Wed, Jul 14, 2010 at 9:41 AM, idan <> wrote:

> That's my JDBC test:
> Regarding the openjpa.Multithread property.. my final application will be
> used in a multi-threaded
> environment.. so i guess i will have to set this property to true.. Am i
> correct?
> I ran the test again with the changes you suggested and i'm getting 1.5x
> than plain JDBC.
> I ran the test a few times and it got consistent after the 3rd time i ran
> the test.
> Any more suggestions? :-)
> Thanks,
> Idan
> --
> View this message in context:
> Sent from the OpenJPA Users mailing list archive at

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