Object-relational Mapping Using JPA, Hibernate and Spring Data JPA. Comparing the performance of persisting entities

We’ll analyze the performances of persisting entities through the three approaches, considering the number of needed dependencies and JAR files to run the project, the number of lines of code to write, and the execution times.

Working with a particular framework will mean that its classes have to be imported into our code and also have to be accessible on the classpath. Fewer classes on the classpath will also mean a lower memory footprint.

Table 1 Maven dependencies, JAR files and lines of code to be written

Table 2 Insert execution times by framework (times in ms)

Table 3 Update execution times by framework (times in ms)

Fig. 3 Update execution times by framework (times in ms)

Table 4 Retrieve execution times by framework (times in ms)

Table 4 Retrieve execution times by framework (times in ms)

Table 5 Delete execution times by framework (times in ms)

Fig. 5 Delete execution times by framework (times in ms)

Conclusions

The three approaches provide different performances from the points of view that were under analysis. The ease of development and the code reduction of Spring Data JPA is impressive (half of the number of lines of code of JPA), but it comes at a price. It requires more dependencies and more JAR files on the classpath (almost 3 times more than for Hibernate). The JPA solution needs all the Hibernate dependencies, plus its own.

There are remarkable notes regarding the execution times. Hibernate and JPA go head to head, the graphics of their times almost overlap for all four operations (insert, update, retrieve and delete). Even if JPA comes with its own API on top of Hibernate, this additional layer introduces no overhead.

For Hibernate and JPA, the update and delete execution times decrease in comparison with the insert execution times. On the contrary, the Spring Data JPA update and delete execution times increase in comparison with the insert execution times.

For Hibernate and JPA, the retrieve times grow very slowly with the number of rows. The Spring Data JPA retrieve execution times strongly grow with the number of rows.

Using Spring Data JPA is justified in particular situations: the project already uses the Spring framework and needs to rely on its existing paradigm (e.g. inversion of control, automatically managed transactions); there is a strong need to decrease the amount of code and thus shorten the development time; the number of manipulated rows at a time is small.

This article has focused on alternatives for working with a database from a Java application: JPA, Hibernate native, and Spring Data JPA and provided examples for each of them.

We implemented Java persistence code using three alternatives: JPA, Hibernate native, and Spring Data JPA.

We created a persistent class and its mapping with annotations.

Using JPA, we implemented the configuration and bootstrap of a persistence unit, and how to create the EntityManagerFactory entry point. Then we called the EntityManager to interact with the database, storing and loading an instance of the persistent domain model class.

We demonstrated some of the native Hibernate bootstrap and configuration options, as well as the equivalent basic Hibernate APIs, SessionFactory, and Session.

We examined how we can switch between the JPA approach and the Hibernate approach.

We implemented the configuration of a Spring Data JPA application, created the repository interface, then used it to save an instance of the persistent class.

We finally compared and contrasted these three approaches: JPA, Hibernate native, and Spring Data JP using a few criteria: the number of needed dependencies, the number of JAR files on the classpath, the number of lines of code to be written, and the execution times for batch processing (insert, update, retrieve and delete operations).

Table 6 Pros of each of the three approaches