jpa-nplus1-fix

First triage the call site: for read-only endpoints use a DTO projection, for managed entities without pagination use JOIN FETCH or @EntityGraph, and for paginated collection fetches use the two-query pattern or batch fetching. Also make all to-one associations LAZY and disable open-in-view.

Use the two-query pattern: paginate entity IDs first with a clean SQL LIMIT, then fetch entities with their collection for just those IDs. Batch fetching via default_batch_fetch_size is a pagination-safe alternative. Never combine JOIN FETCH of a collection with Pageable.

No. Combining a collection JOIN FETCH with Pageable or setMaxResults makes Hibernate drop the SQL LIMIT and paginate in memory, logging HHH000104 (Hibernate 5) or HHH90003004 (Hibernate 6). Use the two-query pattern or batch fetching instead.

It happens when a lazy association is accessed outside an open Hibernate session. Do not fix it by enabling open-in-view or enable_lazy_load_no_trans, which hide an N+1; instead add an explicit fetch at the call site via JOIN FETCH, an entity graph, or a DTO projection.

MultipleBagFetchException occurs when join-fetching two List collections at once. The robust fix is one query per collection, letting the persistence context stitch them onto the same parent instances. Avoid blindly switching to Set, which creates a cartesian product on large data.

Use DTO projections whenever the use case is read-only, such as API responses or exports, because no managed entities means an N+1 is structurally impossible. Use entity graphs or JOIN FETCH only when the caller needs managed entities it will modify.