Hibernate + Spring Data JPA: Lazy Loading Across Transaction Boundaries

The direct answer

No—Hibernate should not return empty collections (or null) for detached lazy associations, and hibernate.enable_lazy_load_no_trans is not a safe general-purpose fix. The portable solution in Spring Data JPA is to fetch everything you need inside the transaction using fetch joins, @EntityGraph, or DTO projections.

Why the exception is the correct behavior

Confirmed: LazyInitializationException is intentional, JPA-consistent behavior. A lazy proxy is a placeholder that only knows how to load data while a persistence context (session) is attached. Once the transaction ends, the proxy cannot know whether the association has zero rows or was simply never loaded.

Returning an empty collection would conflate two very different states:

• "this association was never fetched" (a programming error or missing fetch plan), and
• "this association is genuinely empty" (real data).

Likely explanation for why Hibernate won't adopt it: silently returning empty results would hide N+1 problems and missing-fetch bugs behind plausible-looking data, and business logic built on that data could make wrong decisions (e.g., "customer has no orders" when orders were never loaded). An explicit failure is far easier to diagnose than silent data corruption.

What enable_lazy_load_no_trans actually does

This Hibernate-specific flag (not standard JPA) opens a temporary session for each lazy access outside a transaction. It eliminates the exception, but at real costs:

• Performance: every lazy property or collection triggers its own connection checkout and query. Serializing a detached entity graph (common when returning entities from a REST controller) can produce severe N+1 behavior and connection-pool churn that only surfaces under load.
• Correctness: each association is read in a separate, later transaction, so children may reflect a newer snapshot than the parent entity. You lose read consistency within a single logical request.
• Portability: code depending on it breaks if you ever switch providers (e.g., EclipseLink).

Spring's OpenEntityManagerInViewFilter (the "Open Session in View" pattern, enabled by default in many Spring Boot versions) has the same trade-off: it keeps the session open through view rendering, trading the exception for hidden queries during serialization and longer connection hold times.

The portable fix

Decide what the caller needs and fetch it inside the transaction:

// Option 1: fetch join in JPQL
@Query("select o from Order o left join fetch o.lines where o.id = :id")
Optional<Order> findWithLines(@Param("id") Long id);

// Option 2: entity graph on a derived query
@EntityGraph(attributePaths = "lines")
Optional<Order> findById(Long id);

// Option 3: DTO projection — fetch only what the API returns
@Query("select new com.example.OrderDto(o.id, o.status) from Order o where o.id = :id")
Optional<OrderDto> findSummary(@Param("id") Long id);

All three populate the data with a bounded number of queries, so access after the transaction ends is safe with any JPA provider.

How to verify in your project

1. Load an entity in one transaction, detach it, access the lazy association, and confirm LazyInitializationException with default settings.
2. Enable hibernate.enable_lazy_load_no_trans plus Hibernate statistics (or datasource-proxy), serialize the entity graph, and count the extra per-association queries.
3. Switch to an @EntityGraph or fetch join and confirm one query and no exception after the transaction ends.

Note: exact defaults (including whether Open Session in View is on) vary across Hibernate 5/6 and Spring Boot versions—check your versions before relying on any behavior described here.