[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Eclipselink Vs Hibernate
|
For what it's worth, another comment on caching. Hibernate's approach seems to fit most naturally with the request/response cycles in webapps and outside that (e.g. batch processing, thick clients, ...) is often not ideal, at least in my experience. The last app I wrote first for Hibernate and then retargeted for EclipseLink. The reason was that it a bulk processing component using incremental flushes/commits with high throughput requirements.
With Hibernate I had to come up with various gross work-arounds to avoid flushing and rebuilding the extremely large first level cache. Without these hacks performance was impaired (apparently due to constantly rebuilding objects, etc.), whereas with EcliseLink's 'live' objects and other strategies this became essentally a non-issue. Naturally, caching live objects does have it's pitfalls: one needs to pay special attention when using full identity caching caching lest memory leaks ensue due to references pointing to elsewhere in the heap...
- Jason
On Fri, Jun 19, 2009 at 6:46 AM, Douglas Clarke
<DOUGLAS.CLARKE@xxxxxxxxxx> wrote:
There
are a couple of issues in this last post I would like to add my thoughts
on.
1.
Caching
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.
2.
Partitioning
The
discussion of EclipseLink SessionBroker versus Hibernate Shards may not be a
good comparison. Both offer value but have narrow usage scenarios.
SessionBroker allows multiple databases to be combined together with a single
Session facade where the data is split across databases/schemas by type.
Shards appears to address a different type of partitioning where the same
tables exist in each database/schema and the data is divided across the tables
based on some algorithm (http://en.wikipedia.org/wiki/Partition_(database)).
I
have assisted a few customers over the years in a horizontal partitioning of
their data similar to what I believe shards offers. Using EclipseLink event
framework we were able to send queries to different databases based on data
values and write changes back to the correct database. If there is a
demand for formalizing this support I would be very interested in working with
the community to capture the requirements and documenting how these can be met
with existing EclipseLink features or extending the framework to better
meet their needs.
Doug
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
