Discussions

General J2EE: Hibernate vs EJB 3.0 persistence

  1. Hibernate vs EJB 3.0 persistence (4 messages)

    Hello Gurus,

    We are using Hibernate O/R mapping right now for our projects. And we are thinking to move eventually to EJB 3.0. Can anyone advise someting EJB 3.0 particularly I am interested in persistence 3.0. I looked much in EJB 3.0 persistence spec and I have a feeling that it has become more light weight compared to Entity Beans in 2.0. Has anyone started using new persistence 3.0? How is it peformancewise compared to Hibernate?

    Thanks,
    Vlad

    Threaded Messages (4)

  2. Hibernate vs EJB 3.0 persistence[ Go to top ]

    You cannot compare Hibernate vs EJB 3 because EJB3 is a tecnology
    hibernate _is_just_a_OR_mapping_tool
  3. Implementation vs. Specification[ Go to top ]

    EJB3 is a spec written by the JCP and it is left to others to provide implementations. As it so happens, the lead developer for Hibernate is on the advisory board for EJB3 and Hibernate provides full support for EJB3.

    So if you already are using Hibernate, you can continue to do so even if you want to migrate to the EJB3.
  4. Implementation vs. Specification[ Go to top ]

    Thanks Guys!
  5. Basically,you should not ask what's the difference, but what's the similarity ;). From 10000 feet high, the similarity is that with both you can persist a class in a DB; but it ends there. Period. EJBs are supposed to be components, in the sense that they're not just one class, but a set of classes, descriptors (thats an XML and/or annotations in EJB 3) and usage and management contracts. All of this in order to allow a container (JBoss, Weblogic, etc.) to provide services to those components, and to be able to reuse and distribute this components. This services are, among others, transactions, concurrent access control, security, instance pooling, etcetera. Hibernat is "just" an ORM (Object/Relational Mapping) tool. Quick and dirty, this means you can store an object tree belonging to an class hierarchy in a relational DB without writing a single SQL query. Quite cool, IMO. But no transaction control, no instance pooling, no concurrency control, and certainly no security. On the other hand, inheritance and polimorphism (did i spell it right? sigh...) are IMPOSSIBLE out of the box with EJB. A quite big drawback, i think. The big issue seems to be this days that there's no intersection between Hibernate and EJB's funcionality... what you can with one you can barely do with the other. So EJB 3 is on its way to fill this gap and solve all of our problems. The spec is a draft for the time being, but there are some implementations, already. That's the difference between Hibernate and EJB, in a nutshell. Still, you should expand this concepts with more research, but don't expect to get all of it posting in ANY forum... It's just not polite to ask without having invested some time researching before. It states that the EJB expert group has decided to use Hibernate as the persistence mechanism in EJB 3.0. That’s not how i understood it. EJB 3.0 will provide a POJO object relational mapping much like Hibernate, but i don’t think it will be exactly like Hibernate. From Nilesh jani nilesh_jani@yahoo.com