How
the two frameworks handle caching is one of the primary differentiators.
Hibernate's caching of rows offers a certain simplicity that is one of the
reasons it supports pluggable caching more directly. EclipseLink on the other
hand caches the mapped objects. Caching the mapped objects has its challenges
but over the past 12 years of working with customers using it I have found its
benefits to be worth it. When applications have shared data the performance
cost of rebuilding objects from the row for each usage and the effects on
memory usage versus the possibility of using the same shared instance
should not be ignored.
EclipseLink's object caching and out of the box support for cache
coordination offer impressive benefits. These benefits are greater if there
are more entity types that are read-only (reference data) or read-mostly. For
those more volatile types in the application the developer can easily tune
when EclipseLink re-loads from the database or choose not to store these types
in the shared cache. The caching solution now available in EclipseLink has
evolved over a long period of time based on feedback from the community with
tuneable options to address many different usage scenarios.
We believe strongly in the approach we have taken and its
benefits.
On
the pluggability side we have taken steps to extend our caching solution with
cache interceptors. The intent was to enable grid style solutions to be
plugged in with EclipseLink. Oracle TopLink leverages these extensions to
enable its TopLink Grid functionality integrating Coherence. If there is
interest in plugging in other similar solutions we would be happy to
assist.
The
only caution I offer to users taking up any ORM
solution is to learn how the caching works and tune it for their applications
requirements.
