| Re: [eclipselink-users] Eclipselink Vs Hibernate |
Finally, thanks to James and Sebastien for participating in this discussion and making it lively; the spirit of the discussion is wonderful!
Samba,The SessionBroker functionality has not been dropped. It simply has not been integrated with our JPA implementation. It is completely supported through our native API and is usable with our native metadata used through the JPA interfaces.The solution Sebastien is working on is a broker type solution that implements JPA and sits on top of multiple persistence units. This approach is a much better fit with JPA as it exists now and in the proposed 2.0 specification. We also are looking forward to any contribution Sebastien can make to our community in this area.Within the EclipseLink committers working on the ORM/JPA end of things the focus is on delivering the JPA 2.0 reference implementation within the Java EE 6 schedule. This means bugs targeted for 2.0 that are not directly linked to this effort are blocked behind it. Hopefully as the summer moves along and more of the 2.0 work gets completed we'll have cycles to address the current bug backlog to get as many issues possible resolved for the 2.0 release. We are working to make sure that queue is appropriately prioritized and do make an effort to address user contributed fixes as quickly as possible. If there is a bug you believe should be higher prioritized please add your comments and vote for it. Our weekly open meeting is also a good chance to discuss bugs that are of importance to you.> "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?I disagree completely with this statement.EclipseLink is completely extensible in many dimensions. Over the last 12 years I have solved countless corner cases and challenging customer requirements through use of event listeners, customizers, and custom query types. As we add new functionality we continue to make sure its usage is flexible and extensible.JPA Overhead: When using EclipseLink through JPA there are some different characteristics then when you use our native API. We have exposed query hints such as read-only to allow customers who want more direct access to avoid some of the additional cloning. We believe strongly in JPA but also want to continue to offer our advanced mapping and performance and scalability features through this standard API. It is also possible to mix in use of the native API if there are scenarios where you feel this will meet your needs better.Horizontal Partitioning: I agree that we should start a more formal effort up in this area. Possibly an incubator sub-project. The key to making this work is participation from the community. Requirements, reviews, and verification are key. I will try to at least get the ball rolling on this but I would not expect much resourcing for this until the fall. If you are interested in getting involved that would be great.Hopefully I have touched on all of your points. If not maybe we can start up separate threads for each to make it clear to everyone following this discussion.DougSent: Friday, June 19, 2009 12:38 PM
To: EclipseLink User Discussions
Subject: Re: [eclipselink-users] Eclipselink Vs HibernateHi 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,SambaOn 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. CachingHow 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. PartitioningThe 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
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users