users@glassfish.java.net

Re: FetchType.EAGER behaviour

From: <glassfish_at_javadesktop.org>
Date: Wed, 11 Jul 2007 09:58:11 PDT

Sorry for hijacking this thread, but since our problems are so similar I hope you don't mind...

The cache thing is interesting, but not working. And even if it did, wouldn't toplink still have to do a select on the join table between the two entities in more or less all cases where not every row of the join table is cached? And this would be very impractical if you have, say, 10 million rows in that table. And that's assuming you even have a join table, which in itself might be impossible if you are working with a schema that you don't own.

Example code:
(With toplink.cache.type.default set to Full, or anything else)

level2List = em.createQuery("SELECT x FROM Level2 x").getResultList();
level1List = em.createQuery("SELECT x FROM Level1 x").getResultList();

for (Level2 level2 : level1.getLevel2List()) {
  ....
}

If fetch type is set to LAZY one DB select on Level2 will be issued for each pass through the loop, if fetch type is EAGER all those selects will be issued when level1List is queried above. Setting the cache refresh hint on the queries doesn't make a difference.

As for use cases I would say any use case where you have a tree structure is a valid candidate, and if there is a JPQL query that solves this problem I would love to see it, everything I've tried yields similar results = huge amounts of selects. (Except JOIN FETCH but that only works for trees with 2 levels)

Also, to me this looks as if eager fetching is pointless in most general applications (those not doing very strange things with detached entities), as there is no performance gain in using it over lazy which behaves in exactly the same way when it actually loads the data, but at least has a chance of not selecting data you don't need.
[Message sent by forum member 'cmnordin' (cmnordin)]

http://forums.java.net/jive/thread.jspa?messageID=226207