openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <>
Subject RE: Fetch Group questions
Date Fri, 08 Aug 2008 17:41:26 GMT

  > 2. so if a future OpenJPA version would offer a way to override this,per
attribute not globally, we could leverage that; but it's certainly not
critical.  Do you want a JIRA for this?
   Yes. Why not?

  > 4. Would a JIRA help?
     A JIRA has been created 

   > Q: Is there a runtime API to the @DataCache(enabled=false), some
configuration API to set which classes (globally, given a Class, not an
instance) should be cached and which not?

   Data partitioning strategy for data cache exists at class level. There is
no obvious API that I am aware of to dynamically modify whether a class X
will be L2 cached or not. One can attempt to tinker via
   but side effects of doing so remains unexplored.

> 4 1/2 [NEW] Q: On a Query where an association to a "fully cached"
Entity IS in the FetchGroup, can OpenJPA know this and NOT do the JOIN?
   That is the purpose of 'intermediate' storage of Foreign Key fields being
discussed in this thread. To avoid a join and fetch the related entity if it
is already in cache. Or am i missing something?

> 5. [NEW] Q: Is there any significant runtime performance difference
between putting the @FetchGroup/s annotation on an @Entity and merely
"activating" it through FetchPlan.addFetchGroup(String groupName), as
opposed to "building" it and using lot's of invididual
FetchPlan.addField() ?  Probably not, but I thought I'd ask.

I will hazard a guess that direct addField() may be wee bit faster than
searching for a field in registered fetch groups. But the performance
differential is unlikely to be significant.

View this message in context:
Sent from the OpenJPA Users mailing list archive at

View raw message