Lazy vs Eager Loading & the N+1 Problem

One query loads the orders, then each order's lazy association (customer, items) is initialized with its own SELECT when accessed: 1 + N queries. Confirm by logging SQL and counting statements per request.

• spring.jpa.show-sql=true is crude (stdout, no bind values); prefer logging.level.org.hibernate.SQL=DEBUG and logging.level.org.hibernate.orm.jdbc.bind=TRACE (Hibernate 6).
• Enable hibernate.generate_statistics and assert getPrepareStatementCount() in tests, or use datasource-proxy.

JOIN FETCH loads the association in the same SQL join and initializes it on the returned entities, so the loop does no further queries.

@Query("select o from Order o join fetch o.customer where o.status = :s")
List<Order> findWithCustomer(OrderStatus s);

• Plain join fetch is an inner join; use left join fetch to keep parents with no children.
• Fetching a collection multiplies rows (Cartesian product); Hibernate 6 de-duplicates parent entities automatically, so distinct is no longer needed for that purpose (it only affects SQL if you want it).
• You cannot alias-filter a fetched collection reliably; filtering it makes the in-memory collection incomplete.

Use @EntityGraph on Spring Data repository methods (including derived queries and findAll) to declare what to fetch without rewriting the JPQL; use JOIN FETCH when you need explicit join control or conditions.

@EntityGraph(attributePaths = {"customer", "items"})
List<Order> findByStatus(OrderStatus status);

• FETCH graphs make unlisted attributes lazy; LOAD graphs keep the mapping defaults for them.
• Works with pagination for to-one paths; collection paths still fall into the in-memory pagination warning.

"firstResult/maxResults specified with collection fetch; applying in memory" means Hibernate cannot use LIMIT because the join multiplies rows, so it loads the entire result set into memory and paginates there. It can OOM on big tables.

Fix with two queries:

List<Long> ids = em.createQuery("select o.id from Order o order by o.id", Long.class)
    .setFirstResult(0).setMaxResults(20).getResultList();
List<Order> orders = em.createQuery(
    "select distinct o from Order o left join fetch o.items where o.id in :ids order by o.id", Order.class)
    .setParameter("ids", ids).getResultList();

• Alternatives: batch fetching (@BatchSize) with a paged parent query; keyset pagination; DTO projection with a window function.

When a lazy association of one entity is touched, Hibernate initializes the same association for up to N other uninitialized entities in the persistence context using where id in (?, ?, ...). 101 queries become 1 + ceil(100/N).

• Set globally: spring.jpa.properties.hibernate.default_batch_fetch_size=32.
• It works for collections and lazy to-one proxies, and composes with pagination because the parent query keeps its LIMIT.
• Hibernate 6 may pad IN lists to powers of two for statement-cache reuse (in_clause_parameter_padding).

A lazy association or proxy is accessed after the persistence context was closed (transaction ended, OSIV off, entity serialized in controller, async thread, cache hit returning detached entity).

• Fix by loading what you need in the transaction: JOIN FETCH, entity graph, DTO projection, or map to DTO inside the @Transactional service.
• Do not "fix" it with FetchType.EAGER everywhere or hibernate.enable_lazy_load_no_trans=true, which opens a new session per lazy load (hidden N+1, connection churn).
• Jackson serializing entities is a classic trigger; return DTOs.

Jackson walks the graph: bidirectional links cause infinite recursion (StackOverflowError / JsonMappingException: Infinite recursion), and touching lazy collections triggers N+1 or LazyInitializationException. It also leaks internal fields.

• Use DTOs/records, @JsonIgnore/@JsonManagedReference are patches that couple the model to the API.
• A Hibernate module for Jackson can render uninitialized proxies as null, hiding data bugs.

Enable statistics and SQL logging, and fail tests on excessive statements.

spring:
  jpa:
    properties:
      hibernate:
        generate_statistics: true
        session.events.log.LOG_QUERIES_SLOWER_THAN_MS: 50
logging:
  level:
    org.hibernate.SQL: debug
    org.hibernate.orm.jdbc.bind: trace
    org.hibernate.stat: debug

• Statistics report query counts, entity loads, collection fetches, cache hits and the slowest query.
• Expose Statistics via Micrometer (hibernate.query.executions etc. through HibernateMetrics) for production sampling.

On the inverse side (mappedBy) Hibernate cannot know if the associated row exists without querying, so it must either return null or an object; it queries immediately, making the lazy hint ineffective.

• Fixes: make the child share the parent's PK with @MapsId and query from the child side; use bytecode enhancement with @LazyToOne(NO_PROXY); or model it as @ManyToOne with a unique constraint on the owning side.
• Optional false lets Hibernate use a proxy because existence is guaranteed (owning side only).

A lazy proxy is a runtime subclass of the declared type, not of the actual subtype stored. With inheritance, Animal proxy is not an instanceof Dog even if the row is a Dog.

• Use Hibernate.unproxy(obj) to get the real instance, or visitor pattern or polymorphic methods on the parent.
• Final classes/methods cannot be proxied; Hibernate 6 bytecode-enhancement lazy loading avoids proxies for to-one in some cases.

No; fix the query shape first. The L2 cache (shared across sessions, per SessionFactory) stores entity state by ID, helps find by ID and association loads, but not arbitrary JPQL results unless the query cache is on.

• Enable per entity: @Cache(usage = READ_WRITE) (Hibernate) or @Cacheable, plus hibernate.cache.use_second_level_cache=true and a region provider (JCache/Ehcache, Infinispan; Caffeine through JCache).
• Only worthwhile for read-mostly reference data; entity updates must go through Hibernate to invalidate. Native updates or other services bypass it and serve stale data.
• In a cluster, local caches need replication/invalidation, or use a distributed provider.

Use a DTO projection selecting only needed columns, or move the lob to a separate one-to-one entity. Basic attribute laziness (@Basic(fetch = LAZY)) needs bytecode enhancement (hibernate-maven-plugin with enableLazyInitialization), otherwise it is ignored.

• @Lob Strings/byte[] materialize fully in memory; for big files stream from object storage or use Blob with streaming.
• Splitting the table is the most portable and visible fix.

With OSIV on, lazy loads in controllers and serializers succeed and quietly produce N+1 outside any transaction, each statement using autocommit. Turning it off makes those accesses throw, forcing explicit fetching inside services.

• It also releases the DB connection right after the service transaction ends, which relieves pool pressure for slow responses.
• Migration: enable it off in a branch, fix every LazyInitializationException with a query-level fetch plan, add DTO mapping in services.

size() initializes the whole collection (50,000 rows hydrated) just to count. Better: run select count(c) from Child c where c.parent.id = :id, or drop the mapping and query children via the repository with paging.

• @LazyCollection(EXTRA) is deprecated and still has side effects.
• Large collections should be queried, not mapped; mapped collections suit small bounded aggregates.

Hibernate refuses fetching multiple bags because the Cartesian product makes it impossible to rebuild them correctly. Options: change to Set; fetch one collection per query and let the persistence context merge them; or use batch fetching.

List<Order> orders = repo.findWithItems(ids);     // join fetch items
orders = repo.findWithPayments(ids);               // join fetch payments, same context

• Even with Set there is a Cartesian product (items x payments rows per order), so separate queries are better for large collections.
• Switching to List + @OrderColumn also removes the bag, but adds an index column and update cost.

Copy the SQL with real bind values and run EXPLAIN (ANALYZE, BUFFERS) (PostgreSQL) or EXPLAIN ANALYZE (MySQL 8). Look for sequential scans on large tables, mis-estimated rows, sort spills, and unselective indexes.

• Typical JPA causes: missing index on FK columns (InnoDB creates one automatically, PostgreSQL does not), lower(col) or implicit casts defeating an index, OFFSET deep paging, IN lists with thousands of values, OR conditions.
• Prepared-statement plan caching can choose a generic plan for skewed data (PostgreSQL plan_cache_mode).

@Transactional(readOnly = true) sets Hibernate session to read-only/flush MANUAL: no snapshots for dirty checking, no flush, lower memory and CPU. It may also route to a read replica via a routing datasource and set the JDBC connection read-only.

• Per query: @QueryHints(@QueryHint(name = "org.hibernate.readOnly", value = "true")).
• It does not prevent writes at the DB level in all drivers; writes may just not be flushed (Hibernate) or fail (PostgreSQL honors read-only transactions).
• For truly huge data, project to DTOs or stream with fetchSize.

Use a Stream<T> repository method (or ScrollableResults/StatelessSession) inside a transaction, with a JDBC fetch size, and clear the context as you go.

@QueryHints(@QueryHint(name = "org.hibernate.fetchSize", value = "1000"))
@Query("select e from Event e")
Stream<Event> streamAll();

• PostgreSQL only streams with a cursor when autocommit is off (inside a transaction) and fetchSize > 0; MySQL needs useCursorFetch=true or Integer.MIN_VALUE.
• Close the stream (try-with-resources) to release the connection.
• Keyset pagination in chunks is more robust than a long-lived cursor.

Rarely. EAGER is a mapping-level decision applied to every query for that entity, so each use case pays for it, and JPQL ignores it by issuing follow-up selects. Prefer LAZY mapping and per-query fetch plans.

• Acceptable for tiny, always-needed value collections (e.g. a few roles on a user), ideally via @ElementCollection with @Fetch(SUBSELECT) or an entity graph.
• Two eager bags on one entity fail at startup with MultipleBagFetchException.

On first access of a lazy collection, Hibernate loads that collection for all parents returned by the original query using one query with a subselect of the original query's predicate: where parent_id in (select id from parent where ...).

• Good for a "load parents then all children" pattern without Cartesian joins.
• Can be slow if the original query is expensive (it is re-executed as a subselect) and does not combine well with paged queries.

Hibernate invalidates L2 entries only for changes it performs. Updates from another service, native SQL, DB scripts or JdbcTemplate leave the cache unaware until TTL/eviction.

• Options: short TTL, call SessionFactory.getCache().evict(...) from an event, use messaging-based invalidation, or avoid L2 for shared tables.
• READ_WRITE uses soft locks to keep reads consistent against in-process writes; NONSTRICT_READ_WRITE tolerates brief staleness.

Page queries are JPQL, so EAGER to-one targets are loaded by secondary selects (up to one per distinct target). Set the association LAZY and add @EntityGraph(attributePaths = "customer") to the repository method; to-one fetch joins paginate in SQL fine.

• Provide a countQuery that does not join-fetch, otherwise the count query fails or is slower.
• Sort property names must match entity paths, otherwise PropertyReferenceException.

Replace the loop with one findAllById(ids) / where id in :ids query, then index the results in a Map. Within a transaction the first-level cache avoids repeats for the same ID, but different IDs still cost one query each.

• Chunk very large ID lists (Oracle limit 1000 expressions in IN; PostgreSQL parameter limit 32767 with the JDBC driver 65535).
• For writes, use batch operations rather than per-row save.

Run the use case against a Testcontainers DB with datasource-proxy or Hibernate Statistics, and assert the exact statement count.

Statistics stats = sessionFactory.getStatistics();
stats.clear();
service.listOrders();
assertThat(stats.getPrepareStatementCount()).isEqualTo(2);

• Seed enough rows (e.g. 20 parents) so an N+1 yields a clearly different number.
• Run inside the same transaction semantics as production (OSIV off); @DataJpaTest rolls back and shares the persistence context, which can hide queries because entities are already cached; call em.clear() before the action.

Stop mapping the result to entities. Write a purpose-built query (JPQL constructor expression, native SQL, or JdbcClient) returning flat DTOs, aggregate in SQL (group by), and index for it. For heavy reports consider a materialized view or a separate read table.

• Entities exist for state changes; reads that cross aggregates are better as projections.
• Cache the aggregate result with TTL if tolerant of staleness.

Each call fires a separate select per entity, converting the exception into hidden N+1 and coupling the service to the view's needs. Define the fetch plan in the query (join fetch/entity graph/DTO) per use case.

• Spring Data supports multiple repository methods or named graphs for the same entity, each tailored to a use case.
• Code review rule: any loop that touches an association needs an associated fetch strategy.