EntityManager or Session? Which one to use?

Hibernate first came out in 2001. Among the object-relational mapping frameworks that came up in Java, it was probably the most famous, complete, and successful. It uses Session .

However, Hibernate is a specific framework developed by a specific group. In 2005, several groups met under Sun's coordination to develop and establish an official standard for defining the behavior of object-relational mapping frameworks in general terms. In addition, it was defined that this framework would use the new features of the language of Java 5 (released in 2004), since no mature object-relational framework used them (generic types and annotations, mainly). The work was very inspired by Hibernate and there was a lot of participation from Hibernate staff. From this was born JPA in 2006. JPA uses EntityManager .

Another goal to be achieved with the creation of JPA was the elimination of BMP and CMP from EJB 2 (will not miss it). Basically CMP was an attempt to create a persistence and object-relational mapping specification, but it was quite complicated, difficult to use, strongly coupled with EJB 2, and offered far fewer features than Hibernate. BMP was somewhat closer to what entity beans (annotated with @Entity ) used by JPA today, although they were in a much less developed state. But this is already a topic for another topic.

When JPA was finally born, Hibernate obviously went on to implement JPA, thereby gaining adherence to the official standard and also the use of generic types and annotations. That is, he came to recognize everything the JPA recognizes. In early versions of Hibernate with JPA support, EntityManager redirected everything it did to Session . In newer versions of Hibernate (5.2+), this is even simpler because the Session interface extends the EntityManager interface directly.

However, Hibernate is just one of the existing implementations of JPA (although it is a very good one and is the most successful). Other JPA implementations have emerged. Namely:

• DataNucleus

• TopLink

• EclipseLink

• OpenJPA

• ObjectDB

• Orient DB

• BPA JPA

• Kundera

In fact, the JPA reference implementation, that is, the one that was created to be the basis of the work and prove that the concept works, is EclipseLink.

By using Session directly, you are tying your project to Hibernate. That is, you can not change the JPA implementer. However, you would rarely want to change the JPA implementer, so rarely does this cause a real problem.

These JPA implementations are aggressively competing against each other for performance primarily, and many of them claim to beat Hibernate from far away in various benchmarks. That way, your performance may be better by switching your JPA implementation to something else, but if you use Session directly, you can not make that change. On the other hand, in most cases, performance bottlenecks are elsewhere.

There are some features that Hibernate offers out of JPA. By using Hibernate (not just Session ) directly, you can use them. Obviously, these extra features will not be available in other JPA implementations, at least not through the standard JPA interface.

Well, JPA is a specification. Hibernate is one of the implementations of JPA, that is, implements the specification. Like EclipseLink, TopLink and OpenJPA.

For you to manage your objects with JPA you use the EntityManager (Specification) but if you want to use pure Hibernate without JPA >, you will use Session (Deployment). This depends on the affinity with implementation, need to use in the context of the project, anyway ... The fact is that to have an application that supports changes from Hibernate implementations to EclipseLink for example, you have to adopt the JPA that is, the EntityManager .