Click on components to learn about fetch strategies, or run a simulation to see how data is loaded.

Simulation Legend

EAGER Fetch (Loads immediately)

LAZY Fetch (Loads on demand)

Proxy Object (Placeholder)

Request

Application Layer

UserService

User u = repo.findById(1);
u.getProfile(); // Triggers load

Hibernate ORM

Manages Entity State & Proxies

Network Boundary

PostgreSQL

Users

Profiles

JPA Fetch Types: Eager vs. Lazy Loading

When dealing with relational data in ORMs like Hibernate, you rarely load just one entity. Entities are connected (e.g., a `User` has a `Profile`, an `Order` has `Items`). Fetch Strategies dictate when these associated entities are loaded from the database into application memory.

FetchType.EAGER

"Give it to me NOW"

When you load the parent entity, Hibernate immediately issues SQL queries (often using a JOIN) to fetch all EAGERly mapped child associations. The parent and children arrive in memory together.

Default for: @ManyToOne, @OneToOne

@Entity
public class User {
    @Id private Long id;
    
    // Loaded immediately when User is loaded
    @OneToOne(fetch = FetchType.EAGER) 
    private UserProfile profile; 
}

Danger: Overusing EAGER fetching leads to the "Cartesian Product" problem, loading massive amounts of unnecessary data and slowing down your application.

FetchType.LAZY

"I'll get it when I need it"

When you load the parent entity, Hibernate fetches only the parent data. For the child associations, it injects a Proxy Object. A proxy is an empty shell that looks like the real object but contains no data. The real data is only fetched via a new SQL query when you actually call a method on the proxy (like profile.getBio()).

Default for: @OneToMany, @ManyToMany

@Entity
public class User {
    @Id private Long id;
    
    // A Proxy is injected. Data loaded only when accessed.
    @OneToMany(fetch = FetchType.LAZY, mappedBy = "user")
    private List<Order> orders; 
}

Best Practice: Always prefer LAZY loading to conserve memory and network bandwidth. If you need eager behavior for a specific query, use a JOIN FETCH in JPQL.

The LazyInitializationException

The most famous JPA error. If you attempt to access a LAZY loaded association (triggering the proxy to fetch data) after the database transaction has closed, Hibernate cannot execute the query, resulting in this exception.

The code requests an entity by ID: repo.findById(1).

Depending on the fetch type of its associations, the service either gets a fully populated object graph (EAGER) or an object containing proxies (LAZY).

If LAZY, calling a method on the association (e.g., user.getProfile()) within an active transaction will force Hibernate to go back to the database.

Hibernate intercepts the request and generates the appropriate SQL.

For EAGER: It generates a LEFT OUTER JOIN or multiple immediate SELECT statements to grab all related data at once.

For LAZY: It uses CGLIB or ByteBuddy to generate a Proxy Object. This fake object is placed in the association field. It intercepts method calls and triggers database queries on-demand.

Executes the queries sent by Hibernate.

EAGER loading minimizes the number of queries but might increase the volume of data returned per query. LAZY loading executes more, smaller queries, but only for data that is strictly necessary.

JPA Lazy vs Eager Loading

Component Inspector

Memory State (L1 Cache)