Difference between FetchType LAZY and EAGER in Java Persistence API?

java

lazy-loading

eager-loading

hibernate

byNikita Barsukov·Nov 6, 2024

FetchType.LAZY, as the name suggests, promotes a lazy approach where associated entities are retrieved only when specifically accessed. This proves beneficial with substantial datasets and conserves resource consumption.

Example with FetchType.LAZY:

// These orders take their sweet time and only show up when called for
@OneToMany(fetch = FetchType.LAZY)
private Set<Order> orders;

On the contrary, FetchType.EAGER brings about immediate loading of all related entities as soon as the parent entity loads. While eliminating conditional checks, it can become a potential performance issue with large datasets and complex entity relationships.

Example with FetchType.EAGER:

// These eager beavers rush in before being asked!
@OneToMany(fetch = FetchType.EAGER)
private Set<Order> orders;

Powerful applications leverage the prudence of LAZY loading and the convenience of EAGER loading in balance with the specific business use case.

Behind the curtain: Working with proxies and persistence contexts

With FetchType.LAZY, Hibernate and JPA use proxies or customized collection classes such as PersistentList to implement delayed initialization. However, do bear in mind that these proxies need an open Hibernate session to initialize, so don't rush off closing your sessions!

Factoring in Transactions and Sessions

LAZY fetching ensures that the associated entities are retrieved within a transaction only when the session is alive and kicking. Thus, managing transactions effectively and understanding session boundaries can save you from the dreaded LazyInitializationException or the 'unexpected closed session' surprise.

Beware - EAGER loading and the N+1 selects issue

For FetchType.EAGER, all that glitters is not gold. EAGER fetches can lead to performance hits when dealing with multiple associations. The N+1 selects problem refers to the scenario where an initial query, followed by N subsequent queries for each object returned, results in a total of N+1 SQL queries.

Changing the pace: Transitioning fetch types

Switching fetch strategies from FetchType.LAZY to FetchType.EAGER or the reverse can have significant effects on your application's performance. To get the best of both worlds, advanced solutions like Entity Graphs and Joined Fetching can be put to use.

Above and Beyond Fetching

The role of Caching

Caching in JPA and Hibernate plays a pivotal role in managing resource usage and can work in tandem with fetch strategies. It blurs the performance line between LAZY and EAGER fetching.

Configurations and JPA provider specifics

Different JPA providers may optimize fetching differently. Configuration parameters like hibernate.default_batch_fetch_size can switch the tide for LAZY fetching by reducing SQL queries.

Remember the Context

Real life doesn't follow textbooks! Selecting between EAGER or LAZY should be more about the particular use case than theoretical ideal scenarios.

explain-codes / Java / Difference between FetchType LAZY and EAGER in Java Persistence API?

Linked

Default fetch type for one-to-one, many-to-one and one-to-many in Hibernate



What is this spring.jpa.open-in-view=true property in Spring Boot?



How to fetch FetchType.LAZY associations with JPA and Hibernate in a Spring Controller



What Java ORM do you prefer, and why?



Hibernate error - QuerySyntaxException: users is not mapped [from users]



Hibernate throws MultipleBagFetchException - cannot simultaneously fetch multiple bags



How to map a composite key with JPA and Hibernate?



Behind the curtain: Working with proxies and persistence contexts Factoring in Transactions and Sessions Beware - EAGER loading and the N+1 selects issue Changing the pace: Transitioning fetch types Above and Beyond Fetching