On Jan 16, 2008, at 7:16 AM, Alexander Saint Croix wrote:
Hey, guys.
Is it possible to write an EJBQL query with more than one LEFT JOIN
FETCH
clause?
Sure. Just be careful with outer joins. I always seem to end up
getting too much data with them, and end up using trial and error to
get the query right.
I have a number of entities with more than collection-valued
references that are lazy loaded by default. I'm trying to avoid
flagging
them as FetchType.EAGER.
FWIU, eager fetch and join fetch, only deal with how much data is
loaded and cached in the JPA context and not the query result value.
When it comes to performance of persistent applications, the cache is
typically the thing that makes or breaks the application.
Most JPA examples I have seen use lots of eager fetching, which makes
the example perform really well since all data is available, but
doesn't scale to large data sets. In the real world, your goal is to
only load the data you need for your transaction. If you load too
little, you end up going back to the database which makes the
transaction take longer which leaves your locks open longer which
reduces throughput on the database. On the other hand, if you load
too much data, your application with run out of memory and start
paging, or more likely with the OpenJPA SoftReference chache, your
extra data gets pushed out of memory and then reloaded.
There is a big trade off here (as with all performance base stuff)
between memory usage and time spent processing. There is also a trade
off between raw performance and complexity of your code since all the
performance tuning results in more configuration and/or code. I have
found that more complex code tends to be slower, simply because no one
wants to work on it.
The O'Reilly book on EJB 3 has exactly [--- this
---] much information about JOIN FETCH clauses, and the web's been
less than
forthcoming.
I managed to isolate some patterns in the cascade testing, and am
nearly
done with the the first module for my project. At that point I'll be
tagging a release and redirecting energy toward articles.
I hope this helped. I'm not sure what kind of answer you were looking
for.
-dain
