Hi,
long time no see :).
First, I can tell you that our Weblogic -> Glassfish migration is on
good progress! We already have switch several servers and there are more
to come!
I was struggling with maintaining batch process the other day and was
wondering whether it would be more coder friendly using JPA's native
queries.
I was quite shocked about the performance hit we got: Mind you, we're
NOT using full-fledged Entity beans: just plain SQL! The performance
still was about x4 - x10 worse than using plain JDBC and PreparedStatements!
As the java.net forums seem to be quite dead, I thought it'd be a good
idea to talk to you folks.
So I put up a little test to verify it. You'll find it attached. If you
have Maven2, it should run immediately (after downloading glassfish
embedded 3.1, though...).
It's simple: first, it creates a table "customer" and inserts 1000 rows.
Then it will do "SELECT * from customer" in three different ways:
* via JDBC -> will take under 1s (including call of the session bean)
* via JPA's createNativeQuery -> will take about 4-7 seconds
* via EJB-QL -> will take about 4-7 seconds
It's just doing the select - no parsing of the resultset at all.
I know that it is a very rough test but it does it's purpose: showing
that JPA is much slower than JDBC.
Don't bother about the Derby database (you can start it via
glassfish\javadb\bin\startNetworkServer). I can verify this using a
remote Oracle 10g database on HP-UX.
How come this is so slow? There's no O/R-Mapping involved and the
queries are prepared before calling it - what's taking it so long?
I had big hopes in JPA's native queries for breaking the last plain JDBC
bastion!
Or am I missing some basic thing?
Cheers,
Matthias