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?
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.
"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 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 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 implementation-specific features and functions.
You should follow Cameron McKenzie on Twitter: @cameronmcnz
Interested in more articles and opinion pieces from Cameron McKenzie? Check these out:
- Why the Amazon S3 outage was a Fukushima moment for cloud computing
- Software ethics and why ‘Uber developer’ stains a professional resume
- It was more than user input error that caused the Amazon S3 outage
- Don’t let fear-mongering drive your adoption of Docker and microservices?
- Stop adding web UI frameworks like JSR-371 to the Java EE spec