openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Adams <>
Subject Re: OpenJPA rock and fetch plan is a killing feature.
Date Tue, 01 Feb 2011 21:05:25 GMT
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.


On Tue, Feb 1, 2011 at 11:12 AM, Pinaki Poddar <> 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:
> Sent from the OpenJPA Users mailing list archive at


View raw message