JPA/Hibernate Usability Issues and Solution

By Neha Dhingra

It is not progressive to believe that Java Persistence API (JPA) is ineffective without JPA implementations, but I do consider that we need to determine the appropriate framework depending upon the usability of the API. Although every JPA implementation commercial or open source has some intricacies and defects to be accepted and amendments to be implemented.

JPA/Hibernate Usability Issue

There are moments that JPA can do further harm than good. Following you will comprehend the JPA/Hibernate usability defects and some clarifications to these problems:

Composite Key: These are the significant problem for a JPA developers. Mapping a  composite key is a  huge complexity to the project and the process needed to persist or locate an object in the database using Java classes adds further steps. When you apply a composite key in Hibernate several problems will happen one of them is implementation bugs and handle Java Hash codes for mapping. 

Legacy Database: A  developer often builds a project on a lot of business rules in the database with Hibernate's abstraction level this can be an intricacy while invoking a simple StoredProcedures or  a Functions.

Artifact size:  In Hibernate the artifact size increases a lot with dependencies, that further increases the size of the created jar/war/ear file in the project. For a developer increase in the size of artifacts is difficult to manage if the application is remotely accessed by several servers in low Internet band (or a slow upload). For example, If in an API it is mandatory to add and modify  10 customers servers across the continent. One of the notable problem with slow upload, loss of Internet  and corrupted file can happen to make the development team to lose time in handling discrepancies.

Complex Query: In projects that have high-level  complex queries with accessing database resources like   MIN, SUM, COUNT, HAVING, MAX, etc. If we consolidate those high-end complex queries through Hibernate JPA the task becomes complex using Java classes it's difficult for an unfamiliar developer to handle.

Object Oriented Programming (OOPs) complexity: Performing CRUD operations with Hibernate JPA is a very simple process, however, the  problems appear when we commence using entities relationships mapping through inheritance, caching, PersistenceUnit creations, PersistenceContext among several entities, etc. A team of developers without a with a good JPA experience will dissipate a lot of time  and effort to develop and understand  JPA ‘guidelines‘.


After examining all the obstacles above you might consider a question: “Is Hibernate JPA good?”. JPA has a lot of benefits but that is not to be considered in this post because that is not the theme of the post, JPA is a tool that is indicated for a lot of circumstances. Some of the Hibernate JPA advantages are portability among implementation, reducing development time, making database creation very easy,  2 level cache for optimization, and several tutorial and community support, etc.

In the next section, we will discuss some of the solutions for the problems mentioned above, the solutions could accommodate you to avoid a huge persistence framework problems.

Solutions to  JPA/Hibernate usability Issues

Composite Key

A possible good solution to the composite key would be functional support in JPA though methods and interfaces. Furthermore, If a developer wants to add the composite key in the projects; they can do so using @Embeddable classes. Although the process to create Embedded classes is complex but through these entities a developer can customize the application based on specific business rules. Fig. 1 shows a small example of Embedded classes between Employee and EmployeeID. In the example below EmployeeID is embedded to persist a composite key roleID and EmployeeID.

Fig. 1 Embedded Class

Legacy Databases

To develop an application, in Hibernate JPA, a developer often chooses version  an implementation based functionality support,  to ease the problem the best solution would be to use Eclipse IDE, which adds implicit upgrade support for developers. If a JPA version upgrade is not supported then I don't think JPA would perform optimally. Fig.2 display the easiest way to upgrade version in Eclipse IDE.

Fig .2 Upgrade JPA version In Eclipse IDE

Artifact Size

The easiest solution to artifact size problem would be to develop the JPA implementation using other implementations which suit best in the scenario such as EclipseLink, OpenJPA or Data Nucleus. Although refactoring is a  problem while using hibernate annotation/resources; the change would be advantageous before further load increases.

Generated SQL and Complexes Query

Hibernate solves the complex query problem through its native and JPA specific Query language. Through Hibernate, a developer can create customized named NativeQuery. With so many resources, a developer  could create a simplified query or optimized SQL complex Joins, but because of Hibernate's over ambitious nature a developer has to manage too  much caching while loading objects.

In a project with only one database vendor, the NativeQuery support will not be a difficulty.The advantage of this composite approach Java Persistence Query Language (JPQL) and Hibernate Query Language (HQL) NativeQuery would help the developer to create a complex Stored procedure and Join with such ease and possibly adds to JPA advantages.

OOPs complexity

A possible solution to the problem can be use optimized queries (with NativeQuery), query pagination and small transactions in Hibernate which are easy to implement by an unfamiliar developer.

By avoiding the use of  using EJB with PersistenceContext,  a developer can further extend and reduce memory consumption by increasing processing of the server.A possible solution would get an entity from the database in a read-only format. For example, an entity can be accessed only as a report. Following code below create a read-only entity:

String Qty = "select EDesignation from Employee E";

EntityManager entityManager = entityManagerFactory.createEntityManager();

TypedQuery<Employee> typedQuery = entityManager.createQuery(Qtyquery, Employee.class);

List<Employee> resultList = typedQuery.getResultList();

The code above has no open transaction, all the returned  values in the entities above would not be monitored by JPA. In the case of Enterprise Java Bean (EJB) container a developer has to mark the transaction with @Transactional(readOnly=true).