eBean's autofetch notion was something that we were going to bake into Xcalia long ago, ca. 2005. In fact, Xcalia considered giving the user the ability, most likely via JMX, to ask the PMF to export its tuned fetch plans in metadata form so that they can be included in the metadata. This would allow the app to execute fully tuned after a restart instead of having to retune.
A feature which I think deserves mention here is a notion that Xcalia proposed to the JDO expert group for consideration back before the 2.0 effort: use cases. The idea is that, in addition to fetch plans, other information that is use case dependent (pessimistic/optimistic locking semantics, isolation levels, read-only v. read-write transactions, database-vendor specific options, etc) and exists only to increase performance can be specified in metadata. That way, the performance optimizations available can be made outside of application code, perhaps even at run time via JMX, so you could see the effects of your tweaks immediately. It would allow the user to specify the use case name in a PM/EM property and the implementation would look in the metadata for that use case's descriptor and tune and/or change settings accordingly. We also proposed an API on PersistenceManager as well if programmatic control were needed (kind of defeats the purpose, though): beginUseCase(String useCaseName) and endUseCase(). I would still prefer PM/EM property-based specification of such a concept since the point is to optimize outside of application code. Combine use cases defined in metadata and the ability to autotune and I think you have a winner. I'll have a look at OpenJPA's ResultShape stuff. -matthew On Tue, Feb 1, 2011 at 11:12 AM, Pinaki Poddar <[email protected]> wrote: > > Thanks Matthew, for an excellent elaboration on the fundamental idea behind > fetch plans. > > eBean sure looks like an interesting development in object persistence . The > mechanics to specify fetch path varies in OpenJPA and eBean -- but they are > aiming for very similar goal which is to isolate query filter specification > (the where clause) from the access path -- that SQL traditionally combined > and current JPA continues the tradition via its FETCH JOIN. I especially > liked its idea about AutoFetch -- but missed the OpenJPA's ability to > configure Fetch Plans both at design-time and at runtime (but I have not > looked deep enough in eBean). > > The idea of fetch paths i.e. ability to customize the sub-graph rooted at > instances selected by a query filter is here to stay and has now gained > enough prominence for being a candidate for standardization. I hope many of > your experience in this area be heard when new JPA spec comes out. > > btw, Matthew, on the result shape, you may like the ResultShape constructs > in OpenJPA :) > > > ----- > Pinaki > -- > View this message in context: > http://openjpa.208410.n2.nabble.com/OpenJPA-rock-and-fetch-plan-is-a-killing-feature-tp5978322p5981839.html > Sent from the OpenJPA Users mailing list archive at Nabble.com. > -- mailto:[email protected] skype:matthewadams12 yahoo:matthewadams aol:matthewadams12 google-talk:[email protected] msn:[email protected] http://matthewadams.me http://www.linkedin.com/in/matthewadams
