Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Hibernate now, or wait until EJB 3.0?

 
James Jordan
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We're moving away from JDO (corporate decision, spec is dying).

I don't want to make the same mistake twice.

Hibernate is clearly gaining momentum .... but
-should we wait for EJB 3.0 (rather than have to go through an upgrade cycle)?
-there seems to be a lot of bugs in Hibernate - look at all the user problems on JavaRanch - is this always going to be like this or are things improving?
-we're also looking at straight Data Access Objects, is that a better architecture?


JJ
 
Steven Bell
Ranch Hand
Posts: 1071
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by James Jordan:

-should we wait for EJB 3.0 (rather than have to go through an upgrade cycle)?

In my opinion Hibernate is a better solution, for most products, over EJB 3.0.

-there seems to be a lot of bugs in Hibernate - look at all the user problems on JavaRanch - is this always going to be like this or are things improving?

I havn't run into any bugs in Hibernate. That doesn't mean I havn't posted here looking for some help with it. There is a bit of a learning curve, but if you get a good book it should really ease things.

-we're also looking at straight Data Access Objects, is that a better architecture?
JJ


DAO is more of a design pattern than an architecture. You can use DAO with Hibernate. I would recommend using Spring with Hibernate. The two together make an excellent persistence layer.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

there seems to be a lot of bugs in Hibernate - look at all the user problems on JavaRanch - is this always going to be like this or are things improving?

I think that might be a way to indicate the popularity of product or the relative experience/competence of its users, rather than how buggy it might be.

An often-mentioned point when comparing a specification (such as JDO) with an open source product (such as Hibernate) is the product was born out of necessity, the specification was not. I suspect so long as the need remains, the product will probably stay alive in someway or another. JBoss also now have a contractural requirement to support existing Hibernate users who pay them to, Sun has no such requirement with any of its specifications (as the sudden marginalizing of JDO demonstraits).
[ April 26, 2005: Message edited by: Paul Sturrock ]
 
Stan Sokolov
Ranch Hand
Posts: 120
Hibernate IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Moneywise. EJB 3.0 will use Hibernate internally but provide some extra stuff. EJB 2.0 is an expensive toy that not everybody can afford. Application server and hardware that are reqired for EJB 2.0 should be commercial and top the art accordingly.

If you company can wait until 3.x specification become robust enough to replace existing production solution then just wait a little bit. Hopefully EJB 3.0 would be something great. Otherwise try Spring over Hibernate. Or Hibernate alone. It does not need any investment because all stuff is free.

I am using H3 but if EJB 3.0 give me a chance to be flexible with mapping and use Tomcat I probably would switch.
 
Steven Bell
Ranch Hand
Posts: 1071
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Out of curiosity. What advantages do you see with EJB 3.0 over Hibernate?
 
Stan Sokolov
Ranch Hand
Posts: 120
Hibernate IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Steven Bell:
Out of curiosity. What advantages do you see with EJB 3.0 over Hibernate?


Transaction management for sure. Probably some hierarchy. Cashing. Transaction distribution. Synchronization of Hibernate sessiob between different servers in cluster etc
 
Steven Bell
Ranch Hand
Posts: 1071
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stas Sakalou:


Transaction management for sure. Probably some hierarchy. Cashing. Transaction distribution. Synchronization of Hibernate sessiob between different servers in cluster etc


I would use Spring + Hibernate for Transaction management. Not sure what you mean by hierarchy and caching (in terms of what EJB can do that Hibernate can't/is more difficult).

Distributed Transactions is probably the best reason I've heard of going with EJB 3 over Hibernate. If this is something you need I think EJB is really the only thing out there that makes this managable.

I'm pretty sure Hibernate (or if not Spring + Hibernate) supports clustering over different servers.
 
Stan Sokolov
Ranch Hand
Posts: 120
Hibernate IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nobody says it does not. But probably EJB 3.0 would do it better. Always there is a place to do something better specially if developers have something to copy from.

Example of hierarchy:
Order
Carrier_Order (sub table of order)
Export_Order (another sub table)

EJB 2.0 does not support such hierarchy. IBM offers an extension for WebSphere only.

Example of cash:
Server A in cluster has a Hibernate Factory that create a sessions. Session has some cash. Probably factory has cash as well. If you have two servers in cluster I am not sure that two servers could sinchronize their hibernate cashes. So if server A load an object, changes and persists it. But server B gets the same object from the cash like no changes happened.
 
James Jordan
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry folks ... I was not clear...

Some Hibernate supporters (OK - JBoss staff posting under different aliases) are making a big deal out of the fact that the data persistence parts of EJB 3.0 are going to be based on Hibernate.

Except of course, it won't be exactly the same - and may only follow Hibernate in principle or concept.

That means Hibernate will need to change - and there's a risk of substantial changes....

So, should I wait until EJB 3.0 (data persistence sections) before moving to Hibernate....

In the meantime, I was thinking of just using DAOs... where I can use simple JBDC now under the DAOs but switch to Hibernate later (or whatever something else). I've looked at a tool that can generate DAOs and switch between DAOs for EJBs, Hibernate, JDBC, etc....

Seems the best way forward ... don't forget ... it's an organization that has been stung by using JDO.. so we want to cover our bets
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Whatever you choose -- Hibernate, EJB, JDBC, smoke signals -- wrap it in a DAO layer abstraction so you only get singed instead of burned next time.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Some Hibernate supporters (OK - JBoss staff posting under different aliases) are making a big deal out of the fact that the data persistence parts of EJB 3.0 are going to be based on Hibernate

This is an often-repeated mistake. The persistence stuff in EJB 3.0 looks like it will end up very similar to Hibernate, but it is not based on Hibernate, nor (as stas sakalou writes) does it use Hibernate internally.

David Harkness makes the best suggestion - use a DAO layer properly then you have room to manoeuvre.
[ April 27, 2005: Message edited by: Paul Sturrock ]
 
Stan Sokolov
Ranch Hand
Posts: 120
Hibernate IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
2 Paul:
The EJB 3.0 expert group seems to have handed JBoss the EJB application server market on a silver platter. Several weeks ago at TheServerSide Java Symposium in Las Vegas the EJB expert group announced its decision to shelve the current entity bean architecture and focus on the lightweight persistence of Plain Old Java Objects (POJOs). Specifically, it decided to use Hibernate as the persistence mechanism in EJB 3.0.

http://www.devx.com/opinion/Article/21244
 
Stan Sokolov
Ranch Hand
Posts: 120
Hibernate IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And please spell my name correctly if you cite me
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Apologies for misspelling your name.

If (as you suggest) Hibernate was selected as the persistence mechanism at the recent TheServerSide Java Symposium - which ran from March 3rd 2005 - how does an (unsubstantiated) article dated June 2nd 2004 prove this?

If this were the case, why is it not mentioned in the latest early draft of JRS220 (dated early last month)? Or on either JBoss's site or Hibernate's site? EJB 3.0 will indeed have a POJO based persistence mechnism - but it is Sun's own implementation, not Hibernate.

If you have another source I would be very interested to see it - since this would indeed be big news.

[ April 27, 2005: Message edited by: Paul Sturrock ]
[ April 27, 2005: Message edited by: Paul Sturrock ]
 
Stan Sokolov
Ranch Hand
Posts: 120
Hibernate IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
  • http://www.javaworld.com/javaworld/jw-08-2004/jw-0809-ejb.html

  • The two most significant changes in the proposed EJB 3.0 specification are the use of the program annotation facility introduced in Java 5 and the new O/R mapping model based on Hibernate.

  • http://java.sun.com/j2ee/persistence/faq.html

  • Q: Why didn't you adopt JDO or Hibernate as the persistence API?

    A: We chose to combine the best ideas from several sources in the new persistence API and create a practical, easy to use API to meet the needs of a majority of J2EE and J2SE community members. The persistence interface being developed by the JSR 220 Expert Group will not be based on any single existing persistence framework but will incorporate good ideas contributed by many popular frameworks, including JDO, Hibernate, TopLink, and others.
    JDO is dead. Popularity of TopLink outside Oracle is almost zero. Hibernate is only choice. Thay just affraid to admit that they do not have another choice

    But I can admint that Sun has never declared that it will use Hibernate as only way to manage persistence. By my opinion market already has decided and Sun can only accept this decision.
     
    Pj Murray
    Ranch Hand
    Posts: 194
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by David Harkness:
    Whatever you choose -- Hibernate, EJB, JDBC, smoke signals -- wrap it in a DAO layer abstraction so you only get singed instead of burned next time.


    Usig DAOs regardless of your technology choices is certainly the best approach.

    Don't forget, regardless if which version of Hibernate you use (the current, or a future release that is compliant with the persistence parts of the EJB 3.0 specification), you may still need to upgrade in the future. It's not just the Java persistence technologies that you have to consider, it's also the fact that you may end up upgrading database, application servers, JDKs, etc.

    This is why, of course, that CodeFutures not only recommends using DAOs but also recommends generating the DAOs (and regenerating as appropriate in the future) ;-)

    You may find the following links interesting:




    Choosing a data persistence strategy:

    http://www.codefutures.com/weblog/andygrove/archives/2005/01/choosing_a_java.html

    Data Access Object (DAO) versus Object Relational Mapping (ORM)

    http://www.codefutures.com/weblog/andygrove/archives/2005/02/data_access_obj.html

    Data Persistence Technology Comparison

    http://www.codefutures.com/weblog/corporate/archives/2005/02/data_persistenc.html


    In summary, it's safe for you to move to Hibernate now, provided you take the DAO approach and are prepared to switch persistence technologies/do upgrades in the futures.
     
    Karen Moore
    Greenhorn
    Posts: 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Stas Sakalou:
  • http://www.javaworld.com/javaworld/jw-08-2004/jw-0809-ejb.htmlThe two most significant changes in the proposed EJB 3.0 specification are the use of the program annotation facility introduced in Java 5 and the new O/R mapping model based on Hibernate.

  • http://java.sun.com/j2ee/persistence/faq.html

  • Q: Why didn't you adopt JDO or Hibernate as the persistence API?

    A: We chose to combine the best ideas from several sources in the new persistence API and create a practical, easy to use API to meet the needs of a majority of J2EE and J2SE community members. The persistence interface being developed by the JSR 220 Expert Group will not be based on any single existing persistence framework but will incorporate good ideas contributed by many popular frameworks, including JDO, Hibernate, TopLink, and others.
    JDO is dead. Popularity of TopLink outside Oracle is almost zero. Hibernate is only choice. Thay just affraid to admit that they do not have another choice

    But I can admint that Sun has never declared that it will use Hibernate as only way to manage persistence. By my opinion market already has decided and Sun can only accept this decision.



    Just to help clear up this misconception:
    EJB3 is not Hibernate
     
    Erik Bengtson
    Ranch Hand
    Posts: 90
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by James Jordan:
    We're moving away from JDO (corporate decision, spec is dying).


    The JDO 2 spec is going really well, and the Proposed Final Draft will be out soon.


    Hibernate is clearly gaining momentum .... but
    -should we wait for EJB 3.0 (rather than have to go through an upgrade cycle)?


    Whatever you select today and willing to move to EJB 3 in one or two years, you will have to upgrade.

    Encasulate your persistence code and write unit tests. Feel free to choose the best technology available today and be happy. In a few year, if you need to upgrade, you will have minimized the risk.


    -there seems to be a lot of bugs in Hibernate - look at all the user problems on JavaRanch - is this always going to be like this or are things improving?


    Probably because they made major changes from 2 to 3. You will certainly find bugs. The important is to know their response time to bugs.


    -we're also looking at straight Data Access Objects, is that a better architecture?


    I guess you mean JDBC: This is probably the most, not bad, conservative choice.
     
    Pj Murray
    Ranch Hand
    Posts: 194
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Erik Bengtson:


    I guess you mean JDBC:


    DAOs can and should be used to wrap any of the Java persistence technology choices. JDBC is only one option for DAOs. You should also use DAOs with EJB CMP or Hibernate or JDO or whatever.


    I agree that JDBC DAO is the most conservative/safe choice.
     
    Pj Murray
    Ranch Hand
    Posts: 194
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Karen Moore:



    Just to help clear up this misconception:
    EJB3 is not Hibernate


    It's not a misconception. It's stunningly good marketing and positioning that drove the JDO vendors into a wild frenzy - especially since the EJB 3.0 takes ideas from JDO too.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic