[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipselink-users] Eclipselink Vs Hibernate
|
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.
Doug
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
