Using Hibernate EntityManager

[Treimin Clark]

I have some experiences on JPA (Java Persistence API) and it's EntityManager on J2EE. Now I'm working on a Hibernate application (J2SE) and I'm going to use Hibernate EntityManager library on it. Because it is easy for me, because of my Experiences on JPA.

But I would like to know that how often is this Hibernate EntityManager library is in use in industrial level. What is the best? Using hibernate Session/SessionFactory methods, or Hibernate EntityManager library?

PS- For me, it is little bit hard to memorize methods in JPA and Hibernate together.

[Tim Holloway]

JPA is where Hibernate is headed. In fact, the Hibernate people were some of the primary contributors to the JPA standard. For this reason, I would avoid the old Hibernate Session-based techniques and use the EntityManager - and JPA annotations.

I use Spring and JPA to abstract my persistence layer from the higher levels of the app and it works quite well. In fact, I had one project that was using OpenJPA that ran into a serious problem. I modified the Maven POM to use Hibernate instead of OpenJPA, did a clean/build, and was fully functional with little or no mods to the code and config files. Standards can be wonderful.

[Treimin Clark]

Thanks Tim,

But in many Hibernate books they used the Session based techniques, I didn't see any book which uses the Hibernate EntityManager. This makes me confused. Personally both you and me like to use Hibernate EntityManager library, but what about the industry, what do they really expect?

[Tim Holloway]

Well, my Hibernate book uses Hibernate sessions. But that's because it's older than the JPA option.

JPA was designed to consolidate three different ORM schemes (JDO, EJB and Hibernate) into a single, portable, unified API. It took quite a few years and a lot of shouting to get a standard that everyone would agree on. For one thing, Hibernate was tied pretty intimately to the concept of SQL databases, whereas JDO was designed to work transparently with ANY sort of object-related queries on ANY abstract data collection - whether it was SQL-based, LDAP, or whatever.

Not everyone was happy with everything that came out, but it's a pretty workable standard.

If you're looking for job prospects, I can name shops in this benighted town that think that Struts and pre-JPA Hibernate are cutting-edge technologies and will cheerfully consider hiring you as long as you look cheap enough. But I've moved on and haven't regretted it.

[Treimin Clark]

Thanks Tim, I got it.

[Sagar Kale]

How different hibernate annotations with EJB3? I learned little bit of EJB3 and I know hibernate with xml configuration. So how should I learn hibernate with annotations? Which books should I read? The book which I read is Hibernate in Action does not have annotations.

[Tim Holloway]

Since this is the Jobs Discussion forum, I recommend that you ask Hibernate technical questions in the ORM Hibernate forum. However, a short answer: Hibernate JPA uses the JPA annotations defined in the EJB3 spec. Your Hibernate In Action book is too old for JPA. There's now a Second Edition that covers Hibernate JPA.

[Treimin Clark]

Mmmm, I think the knowledge on JPA is sufficient to follow Hibernate JPA. After the Tim's suggestion, I moved to Hibernate EntityManager library (JPA). There are no high differences between JPA, and EJB JPA, am I right?

[Hong Anderson]

I'm not sure what you mean by EJB JPA, there is only one JPA which is a part of EJB 3 specification (because originally they wanted to simplify EJB CMP).

By the way, I don't like the name JPA, scope of JPA is so narrow, it's only about object-relational mapping, the name should be JORMAPI - Java Object-Relational Mapping API.

[Tim Holloway]

Hibernate JPA is a subset of the full JPA, which EJB3 describes. Hibernate is ORM, but EJB also includes the Session EJBs, which aren't specifically ORM, and which Hibernate doesn't support.

The main reason a name like "JORMAPI" wasn't chosen was because the architecture is ultimately about persistence - reading/writing objects to permanent storage. A better name might be Java Object Relational Persistence Architecture. But the legacy of logic-only objects (Session EJBs) makes things kind of muddy anyway.

[Hong Anderson]

Actually, relational in ORM means relational database, I don't think anybody will argue that it refers to relations in mathematics which the RDBMS is based on. And databases already imply persistence.

But you have a point, maybe the name should be JORM&PA - Java Object-Relational Mapping and Persistence API.

Surely, I cannot change the name, but it's just not right for me. A company likes Sun should educate people, not make people believe more firmly that Persistence is Relational Database.

[Tim Holloway]

Kengkaj Sathianpantarit wrote:Actually, relational in ORM means relational database, I don't think anybody will argue that it refers to relations in mathematics which the RDBMS is based on. And databases already imply persistence.

Actually, somebody will. Several somebodies. One of them is Oracle -> BEA -> Solarmetric, one of the principal vendors of JDO and one of the main contributors to the JPA standard.

In fact, one of the biggest points of contention in JPA was the query language. the EJB and Hibernate communities favored SQL, so that it would be easier to optimize for relational DBMS's. The JSO crowd, on the other hand, wanted to retain their purer "java-only" relational query language that they had been using as a selling point (you only needed to know one "mathematical" language (Java) instead of 2 (Java AND SQL). The final result is a bit of a hybrid.

The JDO product that started out as JPOX - I forget its current name - very specifically allows transparent JPA operation on non-RDBMS data sources such as XML files and LDAP data services.

But you have a point, maybe the name should be JORM&PA - Java Object-Relational Mapping and Persistence API.

Surely, I cannot change the name, but it's just not right for me. A company likes Sun should educate people, not make people believe more firmly that Persistence is Relational Database.

The Mapping part of that is debatable - although the standard may mandate the mapping XML (I'm too lazy to RTFM at the moment), I don't know if the RDBMS mapping is going to carry over too well to something like LDAP. If you get lazy and take the "Object" and the "Relational" as assumptions, that can leave you with just JPA. And, of course, the old saying about assuming things.

[Treimin Clark]

Hmmm, someone turned this thread in to the Object Relational Mapping forum.