Hi 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). -mike On Wed, Jul 14, 2010 at 9:41 AM, idan <ida...@gmail.com> wrote: > > That's my JDBC test: http://pastebin.com/ame6k1CG > > 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: > http://openjpa.208410.n2.nabble.com/OpenJPA-MySQL-performance-overhead-tp5279410p5292879.html > Sent from the OpenJPA Users mailing list archive at Nabble.com. >
