Common challenges of using Hibernate

The Hibernate framework promises to simplify Java application development and database interactions by being a lightweight Object Relational Mapping (ORM) tool. Since it's an open-source and generally highly-regarded, far too many teams seem to be incorporating Hibernate without a second thought.

Before you add Hibernate as a dependency within your microservice, it's important to understand some of the common challenges that come along with it—as we'll discuss here.

Address Coding Fundamentals Before Adoption

When you first give Hibernate a test drive, it can appear as though it's magically annotating everything in your database. The fact is, Hibernate can end up disguising problems you don't realize you have.

Most programmers cannot explain exactly how their application functions. For instance, a piece of code may not explicitly call the save() method, even though the code will lead to something being saved in the database.

Failing to explicitly call methods and use annotations in code is a common problem, and it leads to hard-to-read code that is extremely difficult to comprehend.

When bugs occur, hard-to-read code means reviewers take substantially more time to figure out the fixes.

The answer? Clean up your coding best practices.

If you use Hibernate, it has a way of looking like it's fixing or improving code, although it often ends up disguising bad coding practices.

Hibernate's "magical" annotations aren't at all necessary, or magical—you just need to set new standards for how applications are coded and it will make everyone's job easier.

Beware of Lazy Fetching Issues

Lazy fetch is commonly used in transactions where teams create a lazy field and then refer to it to get a piece of data.

The issue is that this leads to a field that is being added, and then another, and then another. Rarely do you actually need all the data you're fetching, except for one or two fields.

But your application will end up sending a handful of requests to the database and pull objects out completely.

Again, fixing or avoiding this issue is a matter of clean coding practices.

• Lazy fetch should be avoided as it fetches unnecessary data along with the data you want.
• Eager fetch is also bad because it tells JPA to always fetch the data, even when it isn't needed. It also impacts the other code.
• Remember that @EntityGraph requires a separate request altogether.

So, it's best to write something that requests only the data that's necessary. Of course, if you're going to write a request yourself, why use Hibernate at all?

Ensure Proper Configuration of Batch Inserts

When dealing with code that's handling batch inserts, Hibernate can make the job difficult. Proper configuration of this code is a necessity to avoid problems down the road.

The use of Hibernate requires you to add a property to application.yml and create a sequence that increases based on the batch size.

You'll also need to adjust the sequence generator so it's set up to use several sequence values simultaneously, or else Hibernate will refer to your sequence X times.

Since users often forget about the sequence generator, you'll end up with completely un-optimized batch inserts.

However, when properly configured, Hibernate's cascading batch insert can come in handy.

Hibernate requests IDs first; you can set foreign keys to enable cascading saves for relevant entities. However, you can achieve the same result without using Hibernate.

Scalability Challenges with Second-Level Caching

Hibernate features a second-level cache that can cause issues down the road as your microservice scales.

For example, if you use the standard implementation, known as Ehcache, you'll end up with multiple instances storing different data in your cache as your application grows.

This leads to issues with response time, as service response may vary depending on which instance the request finds its way to.

Avoiding the second-level cache is best done by using Spring Cache from the very beginning.

If you do so, you can connect a distributed implementation when scaling to get around the aforementioned issues.

However, if you're using the L2 cache, it's important to remember that you'll still need to connect to the database for each request.

Should I use Hibernate?

As you seek to understand the potential challenges and limitations that come along with using Hibernate, it's important to recognize that there are plenty of use cases and advantages.

However, since so many teams are quick to jump on its implementation in the early stages of development, it's essential that you step back and think the decision through before you add Hibernate as a dependency.

Make sure that you have a purposeful use case for adding Hibernate to your microservices.

Then, make sure you aren't trying to use it as a work-around for challenges or functions that proper coding practices could take care of on their own.

Are you interested in learning more about Hibernate and whether it's a wise addition to your microservices application?

Adservio works with businesses every day to help set them on the path to scalable growth and continued success.

Contact us today to learn more about how we can help you..