Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipselink-users] Eclipselink Vs Hibernate

SessionBroker is not supported with JPA API, it is a dropped functionality from the old native TopLink API: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260258

The implementation on the old native TopLink API just started to be usable, it had lot of bugs: https://bugs.eclipse.org/bugs/show_bug.cgi?id=241681 & https://bugs.eclipse.org/bugs/show_bug.cgi?id=269213

I have just finished to re-code SessionBroker for our client to get something JPA compatible. I will submit  it to the community in the next couple of weeks. I tried to get a neutral layer, so could be used easily with any JPA implementation like Hibernate.

 

EclipseLink is used to have problem with locking, latest are: http://forums.oracle.com/forums/thread.jspa?forumID=48&threadID=909860 & https://bugs.eclipse.org/bugs/show_bug.cgi?id=275046

 

There is a tendency in the development team to cut corner on correctness and thread safety for better performance. So by default Calendar, which is not thread safe itself, is handled by EclipseLink like it is immutable and thread safe by default. Calendar is not thread safe even if never mutated. https://bugs.eclipse.org/bugs/show_bug.cgi?id=252047

 

One of the problem I’m having with EclipseLink Expressions is that when you do a join on unmapped relationship using dynamic code, if you introduce two new ExpressionBuilder(classX) on the same class, you will get 2 times the same table in the from clause so Cartesian product. I’m not sure if a more elegant solution could be available and how Hibernate handle this.

 

EclipseLink JMS invalidation is not J2EE compliant and also not JMS compliant, so  on some server like WebSphere, threads are hanging: http://forums.oracle.com/forums/thread.jspa?messageID=3407365

 

Compared to Hibernate, EclipseLink has no real support to plug-ins other second level cache, they are trying but not really usable at this point. The problem is by design. EclipseLink keeps complete object with their references in the second level cache, where Hibernate doesn’t. So with Hibernate it’s lot more natural to be able to support other cache provider. I heard some Oracle people find Hibernate approach silly, but in reality many of the locking, not thread safe, and other problem with EclipseLink can be link to the design keeping complete object in the second level cache.

 

EclipseLink code is not so easy to reuse/extend, probably because less users are stretching flexibility. https://bugs.eclipse.org/bugs/show_bug.cgi?id=279895 & https://bugs.eclipse.org/bugs/show_bug.cgi?id=274417

 

There is no doubt that a product used lot more than another will be more tested, be more flexible and have more third parties supporting it.

 

What is exclusive to EclipseLink is query in memory. However, in general it’s not leveraged. For example, what is the behavior by default in JPA with default auto-commit?

 

1-      Flush every time before query

2-      Flush only when a too complex query cannot execute in memory

3-      Default to get stale issue by not flushing when should

 

What was positive with the product before JPA, was ease of use for simpler application, because provided Workbench for mapping with some validation. Less cascading options made it look simpler.

 

From: eclipselink-users-bounces@xxxxxxxxxxx [mailto:eclipselink-users-bounces@xxxxxxxxxxx] On Behalf Of Samba
Sent: Thursday, June 18, 2009 5:14 PM
To: EclipseLink User Discussions
Subject: Re: [eclipselink-users] Eclipselink Vs Hibernate

 

James,

 

        Thanks for sharing this info; I feel Eclipselink _expression_ API is more intuitive than JPA Criteia API ;

                            

   I'm actually trying to compare and contrast the Session Broker architecture in EclipseLink and the Hibernate Shards;

   and observed a major difference between the two.

 

 

Here is a summary of what Session Broker is not:

Session Broker Session Limitations

Although the session broker is a powerful tool that lets you use data that is distributed across multiple databases from a single application, it has some limitations:

·         You cannot split multiple table descriptors across databases.

·         Each class must reside on only one database.

·         You cannot use joins through expressions across databases.

·         Many-to-many join tables must reside on the same database as the target object (See "Many-to-Many Join Tables and Direct Collection Tables" for a work-around for this limitation).

 

 Here is what Hibernate Shards is:.

 

 Hibernate Shards addresses the problem of Horizontal parititioning by facilitating a single view ( Java Class )  of the data that may reside across several database servers which essentially means all mapped schema would be identical across all the servers, and Hibernate Shards provides a way to the developers to store different set of records(rows) on different database servers based on predefined/user-extended algorithm. So, in hibernate shards, most probably  Each class will reside on every database.

 

 I believe EclipseLink has the infrastructure to handle these kind of use cases but it needs a little dressing up of the existing Session Broker architecture.

 

Sorry for repeating my earlier question, Can I log feature request asking for eclipselink to support Horizontal Partitioning ( Others may suggest Vertical Partitioning as well)? These advanced database design/maintenence strategies are very much essential for the birth of sites like twitter, linkedin, facebook, etc in Java.

 

Regards,

Samba

On Fri, Jun 19, 2009 at 12:52 AM, Douglas Clarke <DOUGLAS.CLARKE@xxxxxxxxxx> wrote:

Samba,

At JavaOne (CommunityOne) I presented and EclipseLink talk focussed on our JPA 2.0 support. I highlighted the following example of using our _expression_/query API.


> JP QL:

SELECT e FROM Employee e WHERE e.name LIKE ‘D%’


> EclipseLink Expressions:

ExpressionBuilder eb = new ExpressionBuilder();
ReadAllQuery q = new ReadAllQuery(Employee.class, eb);
q.setSelectionCriteria(eb.get(“name”).like(“D%”));
List<Employee> results = JpaHelper.createQuery(em, q).getResultList();


> JPA 2.0 Criteria:

QueryBuilder qb = em.getQueryBuilder();
CriteriaQuery q = qb.create();
Root emp = q.from(Employee.class);
q.select(emp);
q.where(qb.like(emp.get(“name”), “D%”));
List<Employee> results = em.createQuery(q).getResultList();

I just wanted to show how the JPA 2.0 criteria API aligns with our existing _expression_/query framework and how the JpaHelper class can be used.

Doug


-----Original Message-----
From: Samba [mailto:saasira@xxxxxxxxx]
Sent: Thursday, June 18, 2009 2:30 PM
To: EclipseLink User Discussions
Subject: Re: [eclipselink-users] Eclipselink Vs Hibernate


James,

    Thanks for your response.

     Its good to know that Eclipselink _expression_ API is detached and I just came to know that we can use these expressions with

                               ((JpaEntityManager)entityManager.getDelegate()).createQuery(_expression_ _expression_, Class resultType);

   method which returns the standard JPA Query object.

    Also thanks again for letting me know about JSR-303, the Bean Validation Specification.


    In addition to this, I'm interested in knowing a little more about Eclipselink's SessionBroker architecture.

    Is this feature exposed through the JPA entity manager API?

   Something like persistence xml property extentions to specify the session broker configuration xml file would be very helpful.

   It would be great if the JpaEntityManager class makes using the Session Broker transparent of the internal session manager and session broker details.

   If doing these are not possible as of now, can these be taken as a feature request?


Thanks and Regards,
Samba



On Thu, Jun 18, 2009 at 1:39 AM, James Sutherland <jamesssss@xxxxxxxxx> wrote:


I'm not very familiar with these Hibernate extensions, so will do my best to
comment on this.

First off, EclipseLink offers many advanced features not in Hibernate:
- Moxy - object-XML mapping and JAXB
- SDO
- DBWS - database webservices
- EIS
- OR data-type mappings
- Caching and cache coordination
- extended Oracle database and JDBC integration
- TopLink Grid uses EclipseLink

Also many new features are being developed in EclipseLink 2.0 as the JPA 2.0
reference implementation, including the criteria API.

1. Hibernate Validator
- From Hibernate's website this seems to be obsolete, or replaced with "JSR
303: Bean Validation".  So would seem to have little to do with Hibernate
any more, and any such implemention could be used with any persistence
product including EclipseLink.

2. Hibernate Search
- I think Lucene also has an EclipseLink integration.


3. Enhanced Query Facilities like the DetachedCriteria and the HQL on top of
JPQL

- EclipseLink Expressions are always detached, and can even be serialized.
- EclipseLink is adding many JPQL enhancements as part of JPA 2.0.


4. Threadsafeness and Non-blocking data access

- EclipseLink is always thread-safe and non-blocking, and extensive work is
put into ensuring EclipseLink is the most peformant persistence product.

5. Hibernate Shards
- I'm not that familiar with this, but I believe it is similar to
EclipseLink's SessionBroker feature.




saasira wrote:
>
> Hi,
>
>   May I request the eclipselink community to enlighten me on certain
> aspects
> of eclipselink where I could not find convincing answers when eclipselink
> is
> compared with hibernate?
>   Before I start let me make it very clear that I'm not a hibernate fan
> and
> I just want to confirm that eclipselink is not lagging behind in certain
> areas where hibernate advertises
>   that it excels; on the other hand I don't want to bring back the
> infamous
> ORM wars with this mail :)
>
>   To start with, here are the feaures the hibernate website highlights:
>

>      1. *Hibernate Validator* <https://www.hibernate.org/412.html>
>      2. *Hibernate Search* <https://www.hibernate.org/410.html>
>      3. Enhanced *Query Facilities* <https://www.hibernate.org/347.html>,

> like the DetachedCriteria and the HQL on top of JPQL
>      4. Threadsafeness and Non-blocking data access
>      5. Google Contributed *Hibernate

> Shards*<https://www.hibernate.org/414.html>

>
>
>    I know how simplified and powerful Eclipselink native _expression_ API is
> (should I tell you how much I loathe the hibernate criteria API? ), but
> not
> sure if it can be used when the database session is closed, for
> example to build the query from UI layer; and I did not find any JPQL
> enhancements either by eclipselink.
>
>    Also, I found in my googling a search library called Compass which is
> based on Lucene that can be used with eclipselink for searching, but not
> sure how eclipselinkish ( if i can use the word ) its API is while on the
> other hand hibernate search is very much integrated with hibernate core.
>
>    When it comes to shards, I think eclipselink does not have this as of
> now
> (may this be taken as a feature request?).
>
>    Please correct me if have presented anything wrongly here; my intention
> is to get  a better picture of where eclipselink stands when compared to
> hibernate in the above said feature list.
>
>   I know hibernate is no match when it comes to the breadth of the variety
> of datasources that eclipselink supports; but I want to narrow the
> comparision to where hibernate has some foothold and can
>   compete with the monster :)
>
>   The reason I'm doing this is to fight with my friends who work on
> hibernate and tell them that theirs is not the whole world and much more
> lies out side of the confines they have set themselves in.
>
> Thanks and Regards,
> Samba
>
>



-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
--
View this message in context: http://www.nabble.com/Eclipselink-Vs-Hibernate-tp24041213p24081107.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.

_______________________________________________
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

 

Back to the top