Entitymanager or Session? What to use?

Question

I have worked with projects that used both Session and Entitymanager but it was never clear which one to choose. On what basis they differ in terms of performance and compatibility. Someone can give a hint ?

Answer 1

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

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

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

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

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

• Datanucleus

• Toplink

• Eclipselink

• Openjpa

• Objectdb

• Orient DB

• Batoo JPA

• Kundera

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

When using the Session directly, you are tying your project to Hibernate. That is, you cannot change the JPA implementer. However, you would rarely want to change the JPA implementer, so it rarely causes any real problems.

These JPA implementations are competing aggressively against each other for performance mainly, and many of them claim to beat Hibernate by far in several benchmarks. Thus, it is possible that your performance will be better when you change the JPA implementation to another one, but if you use the Session directly, you will not be able to make this exchange. On the other hand, in most cases, performance bottlenecks are elsewhere.

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

Answer 2

Well, JPA is a specification. Hibernate is one of the implementations of JPA, that is, it implements the specification. As well as Eclipselink, Toplink and Openjpa.

For you to manage your objects with JPA you use the Entitymanager(Specification) but if you want to use the Hibernate pure, without the JPA, you will use Session (Implementation). This depends on the affinity with implementation, need for use in the context of the project, finally... The fact is that to have an application that supports changes of implementations, of Hibernate for Eclipselink for example, you will have to adopt the specification of JPA, i.e., the Entitymanager.