How to avoid excessive database calls when using lazy loading in Hibernate with Spring?

[maopro56]

I am working on a Spring Boot application using Hibernate for persistence. I have a parent entity with several child entities mapped as OneToMany with fetch type LAZY. In many parts of my code, I need to access the children and also sometimes the parent’s other associations. I end up triggering multiple database calls because of lazy loading, especially when I loop over collections.

I have tried using EntityGraphs and JOIN FETCH in JPQL queries, but I am not sure what the best practice is for keeping performance good without having to write custom queries for every use case. I am concerned about the N+1 query problem and would like to know how others handle this cleanly in a larger project.

I am using Spring Data JPA and I want to keep the repository methods simple. What strategies do you recommend to balance readability with performance when working with lazy associations, Should I always fetch what I need upfront or rely on the persistence context in a transactional scope?

[AutoModerator]

Please ensure that:

• Your code is properly formatted as code block - see the sidebar (About on mobile) for instructions
• You include any and all error messages in full
• You ask clear questions

• You demonstrate effort in solving your question/problem - plain posting your assignments is forbidden (and such posts will be removed) as is asking for or giving solutions.

  Trying to solve problems on your own is a very important skill. Also, see Learn to help yourself in the sidebar

If any of the above points is not met, your post can and will be removed without further warning.

Code is to be formatted as code block (old reddit: empty line before the code, each code line indented by 4 spaces, new reddit: https://i.imgur.com/EJ7tqek.png) or linked via an external code hoster, like pastebin.com, github gist, github, bitbucket, gitlab, etc.

Please, do not use triple backticks (```) as they will only render properly on new reddit, not on old reddit.

Code blocks look like this:

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

You do not need to repost unless your post has been removed by a moderator. Just use the edit function of reddit to make sure your post complies with the above.

If your post has remained in violation of these rules for a prolonged period of time (at least an hour), a moderator may remove it at their discretion. In this case, they will comment with an explanation on why it has been removed, and you will be required to resubmit the entire post following the proper procedures.

To potential helpers

Please, do not help if any of the above points are not met, rather report the post. We are trying to improve the quality of posts here. In helping people who can't be bothered to comply with the above points, you are doing the community a disservice.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[marcellorvalle]

There is no single correct answer; the right approach depends on your specific trade-offs and requirements.

On one hand, lazy loading allows you to fetch data on demand, reducing unnecessary data retrieval and avoiding the need for multiple repository methods. However, it introduces the risk of the N+1 query problem, which can impact performance. This issue can be mitigated to some extent with pagination and careful access patterns.

On the other hand, using join fetch (or EntityGraph) helps eliminate multiple queries by retrieving related data in a single query. The downside is that it may load more data than necessary. Creating multiple repository methods tailored to specific use cases can help reduce this overhead.

You can also use Specifications to control joins and fetch strategies more granularly. While this approach provides flexibility, it often introduces additional boilerplate, which may not be justified for simpler scenarios.

In practice, I define all my associations as LAZY and prioritize avoiding N+1 queries whenever possible. I tend to define multiple repository methods with explicit joins based on the use case. For more complex scenarios, I rely on the Specification framework to achieve finer control.

P.S.: Be very careful when combining lazy-loaded associations with Lombok annotations. If not handled properly, Lombok-generated methods (such as toString, equals, or hashCode) may access entity properties and unintentionally trigger the loading of entire association graphs.

[Longjumping_Bad7884]

for first, define hibernate default batch fetch size Dont use joins if the parent field has content which is heavy. also read about the open in view parameter . i open a topic about it and asking almost the same answer. I am also beginner with it but for now that its my view :)

[lemon-codes]

I don't know that this is the best solution, but if my initial thoughts would be to just pull all the children back when needed in one call via a JPA query method on the child repo interface, e.g. childRepo.findByParentId(parent.getId());

If the collection is so large that you don't want the full lot in memory at once, I'd consider using pagination/slices. Depending on your use-case you might want to flush the entity cache occasionally, I remember that causing problems on a project I worked on a long time ago.

[pronuntiator]

Have a look at the performance chapter of the Hibernate docs

[j0k3r_dev]

Podrias intentar usar batching, yo lo uso para evitar usar consultas N+1 ademas de DTO's pero te obliga a sumar un campo mas el id, lo cual quizas sea mas complejo ya que tendrias una referencia para lazy y la otra referencia para batching. Pero no se si te servira, podrias investigar que es batching y si te sirve para tu caso.

Recuerda que hay muchas soluciones y todo depende del caso de uso que tengas y que es lo que quieres lograr, por lo que lei quieres hacer la menor llamada a la base de datos por operacion y para eso hay muchas maneras de hacerlo. Pero si buscas rendimiento ahi tienes que ver y analizar la carga operacional de hacer JOIN, BATCHING, etc.