JPA FetchType

FetchType controls whether a JPA association is intended to be loaded lazily or eagerly. It affects when related data becomes available, but it does not by itself guarantee a particular SQL query shape.

JPA defines `FetchType.LAZY` and `FetchType.EAGER` for associations such as `@ManyToOne`, `@OneToMany`, `@OneToOne`, and `@ManyToMany`. Lazy fetching defers loading the associated data until it is accessed, while eager fetching requests that the association be available when its owning entity is fetched.

The default fetch type depends on the association. `@ManyToOne` and `@OneToOne` default to `EAGER`, while `@OneToMany` and `@ManyToMany` default to `LAZY`. Explicitly specifying `fetch` makes the intended behavior easier to understand and review.

With lazy fetching, accessing an unloaded association may trigger additional database work while the persistence context is active. If the entity is detached before the association is initialized, accessing it can result in a `LazyInitializationException` in Hibernate.

Eager fetching can make associated data available immediately, but it can also retrieve more data than a particular use case needs. In practice, query-level techniques such as `JOIN FETCH` or entity graphs are often used when a specific operation needs related data.

Fetch strategy and SQL execution are separate concerns. A provider can use joins, secondary selects, or other mechanisms depending on the mapping, query, and implementation, so `EAGER` should not be interpreted as meaning “always use one SQL join.”

Key points

• `LAZY` defers association initialization until the relationship is accessed.
• `EAGER` requests that the association be available when the entity is loaded.
• `@ManyToOne` and `@OneToOne` default to `EAGER`; collection associations default to `LAZY`.
• Lazy access generally requires an active persistence context.
• `JOIN FETCH` can explicitly request related data for a particular query.

Interview questions

Why can accessing a lazy relationship throw LazyInitializationException?

A lazy association may not have been initialized when its entity is detached from the persistence context. If application code then accesses that association, Hibernate may have no active persistence context from which to load the missing data. It can therefore throw `LazyInitializationException`. A common solution is to fetch the required relationship within the transaction using an appropriate query or entity graph.

What is FetchType in JPA?

FetchType specifies how JPA should load an entity association. `LAZY` means the related entity or collection can be initialized only when it is accessed, while `EAGER` requests that it be available when the owning entity is loaded. It applies to relationships such as `@ManyToOne` and `@OneToMany`. The exact SQL strategy is provider-dependent.

What are the default FetchType values for common JPA relationships?

Single-valued `@ManyToOne` and `@OneToOne` associations default to `EAGER`. Collection-valued `@OneToMany` and `@ManyToMany` associations default to `LAZY`. These defaults can be overridden explicitly with the `fetch` attribute. Knowing the defaults matters because an omitted setting does not mean every relationship behaves the same way.

Does FetchType.EAGER guarantee that JPA will use a SQL join?

No. EAGER describes the required availability of the association, not a specific SQL formulation. A JPA provider can satisfy that requirement through joins or additional SQL statements depending on the query and implementation. Therefore, changing an association to EAGER is not a reliable way to control SQL performance.

How would you fetch a lazy association when a particular use case needs it?

One common approach is a JPQL query using `JOIN FETCH`, which tells the provider to retrieve the required association as part of that query. Entity graphs are another option for defining fetch requirements separately from the query text. The choice depends on the query and application design. The important point is to fetch relationships according to the use case rather than making everything eager globally.