Diagnosing and Fixing LazyInitializationException in Spring Data JPA

Recognizable condition

A LazyInitializationException with the message could not initialize proxy - no Session appears when code touches an uninitialized lazy association (a @OneToMany collection, a @ManyToOne with FetchType.LAZY, etc.) after the persistence context (the Hibernate Session/JPA EntityManager) has been closed. The stack trace usually points to a getter or a Jackson serializer walking the object graph in the web layer.

Why it happens – cause/diagnostic table

Observed symptom	Typical root cause	Where to look first
Exception thrown in controller or JSON serializer	Repository returns an entity; the @Transactional boundary ends at the service method, then the web layer accesses a lazy proxy.	Service method return type and transaction annotation.
Exception appears only after setting spring.jpa.open-in-view=false	Open‑in‑view was masking the problem by keeping the EntityManager open for the whole request.	Application properties / YAML.
Exception in @Async or scheduled task	Background thread never inherits the request‑scoped session; each thread needs its own transaction.	Async configuration and transaction boundaries.
Cartesian‑product warning (HHH000104) when using fetch joins with pagination	Fetch join on a collection combined with Pageable forces in‑memory pagination.	Query method signature and pagination usage.

Ordered diagnostic checks

1. Read the stack trace – identify the exact association (field name, owning entity) that failed to initialize.
2. Locate the transaction boundary – find the @Transactional method that loads the entity. Note where it returns and where the lazy access occurs (controller, mapper, DTO converter, Jackson).
3. Check spring.jpa.open-in-view – default is true in Spring Boot 2.x/3.x. If it is true, the exception is hidden; set it to false in a test profile to surface all latent cases.
4. Determine the access context – is the lazy access happening during JSON serialization, a MapStruct/Mapper conversion, a Thymeleaf view, or custom code?
5. Inspect async / thread‑hop paths – any @Async, CompletableFuture, or scheduler callback that touches entities must open its own transaction.

Fixes tied to each finding

1. Fetch the needed data inside the transaction

If the association is genuinely required, load it before the transaction ends. Three common approaches:

• JPQL / Criteria fetch join – SELECT a FROM Author a JOIN FETCH a.books WHERE a.id = :id
• @EntityGraph – define a named graph on the entity and reference it in the repository: @EntityGraph("Author.books") Optional<Author> findById(Long id);
• Explicit initialization – Hibernate.initialize(author.getBooks()); inside the service method.

Choose the fetch join or entity graph when the graph is small and stable; use explicit initialization for conditional loading.

2. Map to a DTO inside the transactional service (recommended)

Return a plain data‑transfer object that contains only the fields the client needs. The web layer never sees JPA proxies, so no lazy access can leak out.

@Transactional(readOnly = true)
public AuthorDTO getAuthorWithBooks(Long id) {
    Author author = authorRepository.findById(id)
        .orElseThrow(() -> new EntityNotFoundException("Author", id));
    // fetch join or entity graph ensures books are loaded
    return new AuthorDTO(author.getId(), author.getName(),
        author.getBooks().stream().map(Book::getTitle).toList());
}

This pattern also eliminates N+1 queries because the fetch strategy is explicit.

3. Widen the transaction boundary – last resort

Annotate the controller method with @Transactional or move the lazy access into the service. This keeps the session open longer but couples the web layer to the persistence context and can cause connection‑pool contention. Use only when refactoring to DTOs is impractical.

4. Disable open‑in‑view to catch regressions early

Add to application.yml (or .properties) for a test profile:

spring:
  jpa:
    open-in-view: false

Run the full test suite; any endpoint that now fails pinpoints a lazy‑loading leak. This is a deliberate engineering trade‑off many teams adopt to surface N+1 and boundary issues before they reach production.

5. Async / scheduled paths – give each thread its own transaction

Wrap the background work in a service method marked @Transactional and call that method from the @Async task. Do not pass entities across thread boundaries.

@Async
public void processAuthorAsync(Long authorId) {
    authorService.enrichAndStore(authorId); // @Transactional inside
}

Escalation criteria

• Fetch joins cause HHH000104 (in‑memory pagination) – split the query: first fetch IDs with pagination, then load entities by ID list, or enable batch fetching via hibernate.default_batch_fetch_size (e.g., 20).
• Exception only in async/scheduled code – redesign so each background job opens a fresh transaction; never reuse a request‑scoped EntityManager.
• Entity graph grows unbounded – if the object graph becomes too large for a single fetch, consider a dedicated read model or projection query instead of loading the full entity tree.

Verification steps you can run locally

1. Minimal reproduction test – write a JUnit test that loads an entity with a lazy collection inside a @Transactional method, exits the method, then accesses the collection. Expect LazyInitializationException.
2. Toggle open‑in‑view – create a test profile with spring.jpa.open-in-view=false and execute the web‑layer integration tests (e.g., @SpringBootTest + MockMvc). Failures identify endpoints that rely on out‑of‑transaction lazy loading.
3. Confirm SQL reduction – enable Hibernate SQL logging (see below) and verify that a fetch join or entity graph eliminates the extra SELECT for the association.

Enabling SQL logging (run in the application process)

# application.yml (or via command line)
logging:
  level:
    org.hibernate.SQL: DEBUG
    org.hibernate.type.descriptor.sql.BasicBinder: TRACE

Observe the console or log file: a single query with a join should replace the original entity load plus a separate collection load.

Limitations & practical checks

• Fetch joins on collections combined with Pageable still trigger in‑memory pagination on Hibernate 5.x and 6.x; the safe pattern is to paginate IDs first.
• spring.jpa.open-in-view default and semantics can differ between Spring Boot 2.x and 3.x; verify the version you run before relying on the flag.
• Switching associations to FetchType.EAGER to silence the exception is an anti‑pattern – it typically creates N+1 queries and unbounded graph loading elsewhere.

Quick checklist for code reviews

• Does every repository method that returns an entity used outside a transaction have a matching fetch strategy (join, entity graph, or DTO projection)?
• Is open-in-view disabled in CI test profiles?
• Are async/scheduled tasks annotated with their own @Transactional boundaries?
• Are batch fetch sizes configured for high‑cardinality collections?

Following these steps turns a cryptic LazyInitializationException into a clear signal about transaction boundaries and data‑fetching strategy, letting you fix the root cause rather than masking it.