[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Eclipselink Vs Hibernate
|
Hi Sebastien,
Thanks a lot for taking time to compile the pressing issues in eclipselink, atleast those related to the topics that we discussed here;
I believe these kind of retrospective discussions will be ultimately helpful to the product and the community.
And it is good to know that you have fixed some existing issues in the Session Broker; I'll be looking forward for eclipselink bundles that have your solution to the problem, as is or adapted to the overall eclipselink architecture. It is good to see that the enhancement request raised by Doug himself (albeit low priority) is getting a solution from the community.
Every product has bugs and as long as the community is active, one need not worry too much as its only a matter of time before issues get fixed.
I believe the issues you mentioned like concurrency,locking and non-JEE-compliant JMS notifications are worth taking on with a priority higher than P3.
A dzone article about the issue mentioned in bug-274417, but related to fiddling with hibernate is here
http://netbeans.dzone.com/news/netbeans-and-jpa-with-multiple ; it looks like several persons are trying to solve the same problem in their own way. Shouldn't it be addressed at the spec level as Doug mentioned in the comments for this bug?
I'm really surprised to hear that Session Broker is a dropped functionality; its value can be enormous for any project that has to be designed for scalability and performance. Perhapas the Giants like Oracle or DB2 may handle petabytes of data in a single database but not all database systems offer such luxury.
So, in order to be scalable we have to design our schema in such a way that the data is distributed across the clusters and no single node is drained out of resources at any point in time. Session Broker offers one of the ways to achieve this and the other being the Hibernate Shards approach; both seems to be solving the same problem but each in its own way, and each has its own applications.
Doug,
"EclipseLink code is not so easy to reuse/extend, probably because less users are stretching flexibility" ---- If there is any truth in this comment, don't you think a re-look at providing extention points is required?
Another question that comes to mind often is to estimate the amount of overhead at runtime spent by JPA wrapper to comminicate to and fro the native toplink code. Do you think if there is any possibility for this overhead to cause performance botttlenecks in a heavily loaded system? Has there been any tests written in this regard?
About Caching, I agree with Doug that many people would go with using eclipselink internal cache provider unless they have a more performant cache provider, or for intergating with distributed systems like Coherence or Gigaspaces. Nevertheless, these use cases cannot be ignored; hence providing hooks to plugin additional cache providers adds flexibility for eclipselink to be integrated with any system of user's choice. If there is any existing feature request regarding this issue, please let me know so that I can vote for it.
Another important feature request I would like to make is for eclipselink to support horizontal partitioning ( I think Vertical partitioning is very difficult to implement). Since you mentioned that you have earlier worked with a customer to achieve this with erstwhile toplink, I hope it would not be too much to ask for generalising that solution and adding it to eclipselink, perhaps to 2.0 trunk.
Thanks and Regards,
Samba
On Fri, Jun 19, 2009 at 6:16 PM, 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
