carmelo said:
Thank you guys for your answers.
< how slow is slow? Roughly how many seconds for what size result
sets?
59 seconds for 439 records!
I load a 3,000-entry List from JPA over a relatively slow network in one
project virtually instantly. It's not JPA that is at fault.
I don't bother with pagination when I'm using JPA. It ends up defeating the
internal caching and available external caching capabilities of the JPA
provider. It also messes up your architecture.
When you use JPA, you need to avoid thinking of your persistent information as
"data". The whole point of JPA is to give an *object-oriented* view of
persistent entities and their relationships. The fact that you are tangled in
questions of "performance" (and trying to blame JPA for it) and "batches"
indicates that you are not working from an object-oriented view of your
architecture. That is the real mistake.
You get the best performance out of JPA when you use it in its natural mode.
Then it's quite fast, at least as much so as normal database access will let
it be. Done properly, it'll never be "JPA" that is to blame for performance
issues.
You have given us absolutely no information about the data or object models
you use, or how you try to integrate them. Then you expect miracles from
Usenet to solve your problem, while you go haring off after chimeras like "JPA
hurts performance". It doesn't work that way.
Well, I guess it does, now that you are reading this post.
JPA has built-in support for certain natural kinds of "batches", that is,
one-to-many, many-to-one and many-to-many relationships of entities or sets of
entities to each other. It fills these batches quite efficiently
appropriately to the programmer's choice of 'Fetch.EAGER' or 'Fetch.LAZY'.
The former uses JOIN syntax (assuming proper integrity constraints in the
database) and the latter conditional queries.
With only 439 entities ("records" is a data-oriented term) you don't need to
page. That's just silly.
If you keep entity size reasonable, let's say about a KiB apiece, you can hold
a thousand per MiB. In batch sizes over about ten thousand it starts to
become useful to think about paging.
Proper data models on the database side are an absolute must. Screw up the
data model and too bad for you.
JPA works best for simpler data models, ones that have clean representations
of entities. It can handle beautifully any relationships expressible in
collection terms, and since relational databases are set oriented by
definition, that is anything that a relational database expresses.
As relationship complexity grows, particularly with many-to-many links, the
@JoinX() annotations become mandatory. You have to get pretty specific in
your mappings, telling JPA not only the fields through which you link but the
table and column names involved.
The Java EE 5 tutorial on java.sun.com goes through some of this, and googling
around will find you more examples. I find the documentation for each of
EclipseLink, Hibernate and Apache OpenJPA all to be very useful, regardless of
which one you actually happen to use.