The JPA 2.0 EntityManager vs. the Hibernate Session: Which one to use?

It's the age-old question that almost all enterprise data architects have to ask themselves at some point in time: When using the Hibernate ORM framework with the Java Persistence API (JPA), should data access be mitigated through the JPA 2.0 EntityManager or through the underlying Hibernate Session? Well we have some answers for this JPA vs Hibernate comparison debate.

EntityManager is part of the Java Persistence API (JPA) standard, and who can really argue against using something that is standardized? But, of course, the problem with a standard is that it often represents the lowest common denominator with regards to what everyone in the community can agree upon. And who wants to use the tool that represents the lowest common denominator?

At the other end of the spectrum is the Hibernate Session, the integral part of the Hibernate ORM ecosystem that provides CRUD-based interactions with persistent entities. It is JPA compliant, so it can do everything the specification does, but it is not confined to the JPA standard, and as such, it has a vast array of interesting features that might compel developers to ditch the EntityManager with a vengeance.

From a team point of view, we wish we had only one API. We are really trying to push into the standard as much as we can.

Emmanuel Bernard, 
Data Architect. 
Hibernate

We posed the EntityManager versus Hibernate Session question to Emmanuel Bernard, a data architect on the JBoss Hibernate team. His answer was without reservation.

"We encourage people to use the EntityManager," said Bernard, demonstrating no romantic fondness for the objects and methods that are unique to the Hibernate implementation. "From a team point of view, we wish we had only one API. We are really trying to push into the standard as much as we can. If we could somehow merge or deprecate the session in the future we would do it, but people still use some stuff that is not in the EntityManager, and we don't want to just break everybody's application just for the fun of it."

But what about all of the neat features and functions that the Hibernate JDBC implementation provides that can't be accessed through the standardized EntityManager? "You can always access the Hibernate Session, which is right underneath," said Bernard, referencing the unwrap method of the EntityManager that became available in JPA 2.0.

So that pretty much settles it. Given the opportunity, deference should be given to the standardized EntityManager, not the implementation-specific Hibernate Session. Perhaps in the days of JPA 1.x, the argument may have gone a little bit differently, as the standard still lacked a strong Criteria API, and obtaining the underlying JDBC or ODBC implementation class from the standard components was more difficult, but those issues have been largely addressed in the latest JPA releases. Given the choice, it's best to use the EntityManager, especially knowing that the Hibernate Session can still be easily unwrapped when the need arises to access JDBC specific features and functions.

You should follow Cameron McKenzie on Twitter: @cameronmcnz