Hibernate has a setting, hibernate.enable_lazy_load_no_trans, that lets lazy associations load even when no persistence context is open. Why do experienced teams treat turning it on as an anti-fix rather than a solution?

## What the setting actually does `hibernate.enable_lazy_load_no_trans` (default `false`) changes what happens when an uninitialized proxy or collection is accessed and no usable session is available. Instead of throwing, Hibernate opens a **new, temporary session**, begins a transaction on it, executes the deferred `select`, commits, and closes the session — for that one access. The next uninitialized proxy you touch repeats the whole cycle. That is the entire feature. It is not a caching or batching mechanism, and it does not re-attach the object graph to anything. ## Why it breaks correctness A unit of work exists so that everything you read comes from one consistent snapshot of the database. When lazy loads escape into ad-hoc transactions minutes later, that guarantee is gone: - An `Order` loaded at T0 may be paired with a `Customer` row read at T1 and `OrderLine` rows read at T2. The customer may have been renamed, the lines may have been deleted, the order may itself no longer exist. Nothing detects this. - Aggregates computed over such a graph — totals, counts, validations — can be arithmetically impossible. - If the original transaction rolled back, you can still load and display the associations of an object whose owning change never happened. This is precisely the failure Hibernate refuses to cause when the setting is off. ## Why it breaks performance and operations The access pattern that triggers it is almost always iteration: a serializer walking a list, a template rendering rows, a mapper copying fields. So the cost is per element: - one connection checkout per lazy access, from the same pool your request threads need, - one transaction begin/commit round trip per access, - one `select` per access, unbatched and unplanned. A list of 500 rows whose serializer touches two associations each can turn into 1000 short transactions. And because they happen **after** the service transaction committed, they usually run while the response is being written — the point where you have the least ability to time-box or roll back anything. Latency graphs show it as slow serialization, not as slow database access, which makes it hard to attribute. There is also a subtle resource risk: connection acquisition happens outside your normal transactional boundaries, so pool exhaustion under load shows up in code that looks like pure rendering. ## Why it destroys a useful signal `LazyInitializationException` is one of the few places where a persistence framework tells you, loudly and early, that your **fetch plan does not match your read plan**. It fires in tests, in CI, on the first exercise of a path. Enabling the setting converts every such mismatch — present and future — into extra queries that nobody will notice until a load test or a production incident. You have not fixed anything; you have removed the detector. This is what makes it an *anti*-fix rather than merely a suboptimal fix: it is global, it is invisible at the call site, and its cost grows with data volume, which is exactly the profile of a defect that ships. ## It does not even cover the cases people hope for - If the entity was **serialized** (session-to-session, cache, HTTP) the proxy is dead in a way the setting cannot rescue. - If the object crosses into another thread or another node, there is no session and no meaningful transaction to associate the load with. - It gives you no control over the graph: you still cannot state "this API returns orders with their lines" anywhere a reviewer can see. ## What to do instead Decide the graph at load time: - **Projection** into a DTO when the consumer only reads fields — no proxies exist afterwards, so the question disappears. - **`join fetch` or an entity graph** when the consumer needs managed entities with a known subgraph. - **Initialize explicitly inside the transaction** for one-off cases, accepting that the plan now lives in code. - **`@BatchSize` / subselect fetching** to make in-transaction lazy access cheap when the graph genuinely varies. And keep the failure loud: leave the setting at its default, and prefer boundaries where objects leaving a service are either DTOs or entities with a documented, tested graph. ## If you find it enabled Treat it as a migration task, not a flip. Turn it off in a test environment first, let the exceptions point at every mismatched read path, fix those with queries, and only then change the production configuration — otherwise you trade silent slowness for a burst of user-visible errors.