What this usually means
Hibernate uses lazy loading proxies to avoid fetching related entities until explicitly accessed. The proxy requires an active Hibernate Session (EntityManager) to initialize itself. When you access the proxy outside a transaction or after the session has closed, Hibernate throws LazyInitializationException. This typically happens in three scenarios: (1) you've disabled OpenSessionInView (OSIV) and access lazy collections in the view/serialization layer, (2) you're using DTOs but inadvertently trigger lazy loads before the session closes, or (3) you have a transaction boundary issue such as calling a service method that returns an entity with lazy associations, then accessing those associations in the caller that has no transaction. The non-obvious part: even with OSIV enabled, you can still get this error if the session is closed prematurely due to serialization, caching (e.g., second-level cache with lazy entities), or when entities cross thread boundaries (async).
The first ten minutes — establish facts before touching code.
- 11. Check if spring.jpa.open-in-view is enabled in application.properties (default is true). If false, that's likely the cause — but don't just set it to true without understanding the tradeoff.
- 22. Reproduce the error with a minimal test: call a repository.findById() in a @Transactional service, then access a lazy collection inside the same method. If it works, the issue is transaction boundary.
- 33. Look at the stack trace: identify which line triggers the lazy load. If it's in a Jackson serializer or Thymeleaf template, the session is closed by then.
- 44. Add logging: set logging.level.org.hibernate=TRACE to see when the session opens and closes. Look for 'SessionImpl#close' before the error.
- 55. Check if the entity is being serialized (JSON/XML) and if you have @JsonIgnore or @JsonBackReference on lazy fields. Without it, Jackson triggers lazy loads.
- 66. For batch jobs or async methods, verify that each unit of work has its own @Transactional boundary.
The specific files, logs, configs, and dashboards that usually own this bug.
- searchapplication.properties or application.yml: check spring.jpa.open-in-view, spring.jpa.properties.hibernate.enable_lazy_load_no_trans, and transaction timeout settings.
- searchStack trace: identify the exact line where the lazy association is accessed (e.g., a getOrders() call on a Customer entity).
- searchEntity classes: check annotations on associations — @OneToMany(fetch = FetchType.LAZY), @ManyToOne(fetch = FetchType.LAZY).
- searchService layer: verify @Transactional annotations are correctly placed on public methods that will access lazy data.
- searchController/DTO mapper: look for direct entity access in view templates (Thymeleaf, JSP) or during JSON serialization (Jackson, Gson).
- searchAsync configuration: for @Async methods, ensure the calling method is not holding the entity across the async boundary without a new transaction.
Practical causes, not theory. These are the things you will actually find.
- warningOpenSessionInView filter is disabled (default since Spring Boot 2.0 changed? Actually default is true, but many teams disable it for performance).
- warningEntity is serialized (JSON/XML) before the session closes — Jackson triggers lazy load after the transaction commits.
- warningService method returns an entity to a non-transactional caller (e.g., controller) and then lazy data is accessed in the view.
- warningUsing @Transactional on private methods (only works on public ones).
- warningCross-thread access: passing an entity to another thread (e.g., @Async) where the original session is closed.
- warningSecond-level cache or query cache returns a proxy that is detached from the session.
Concrete fix directions. Pick the one that matches your root cause.
- build1. Enable OpenSessionInView (spring.jpa.open-in-view=true) as a short-term fix, but be aware of connection pooling issues and performance degradation.
- build2. Use DTOs/projections to avoid exposing lazy-loaded entities to the view layer. Fetch only the data you need in the query (JPQL with JOIN FETCH, EntityGraph, or @Query).
- build3. Add hibernate.enable_lazy_load_no_trans=true to application.properties — this creates a temporary session for each lazy load outside a transaction. Warning: N+1 queries and performance disaster.
- build4. Restructure transaction boundaries: move the lazy data access inside a @Transactional service method, e.g., use a service method that returns a fully initialized DTO.
- build5. For serialization: annotate lazy fields with @JsonIgnore, @JsonBackReference, or use Jackson's @JsonView. Better: use DTOs and map with MapStruct.
- build6. For async: copy the necessary data to a DTO within the transaction before passing it to the async method.
A fix you cannot prove is a guess. Close the loop.
- verified1. After applying the fix, reproduce the exact scenario that caused the error (e.g., call the REST endpoint that failed).
- verified2. Check logs for absence of LazyInitializationException and confirm Hibernate session lifecycle: session opens, lazy loads happen, session closes cleanly.
- verified3. Run integration tests that access lazy associations from the view layer (e.g., mock MVC with JSON output).
- verified4. Profile the database queries: ensure the fix didn't introduce N+1 queries (use Hibernate statistics or datasource-proxy).
- verified5. For OSIV fix: verify that connection pooling is not exhausted under load (monitor active connections).
- verified6. For DTO fix: confirm that no lazy proxy leaks into the serialized output (use a custom serializer test).
Things that make this bug worse or harder to find.
- warningDon't blindly set hibernate.enable_lazy_load_no_trans=true — it causes N+1 queries and can bring down the database.
- warningDon't enable OpenSessionInView in a production environment without monitoring connections — it holds DB connections until the view renders, causing pool exhaustion.
- warningDon't make all associations FetchType.EAGER — that leads to massive joins and performance degradation.
- warningDon't ignore the root cause by catching the exception and returning null — you'll get NPEs elsewhere.
- warningDon't use @Transactional on private methods — it has no effect (Spring proxies only intercept public calls).
- warningDon't serialize entities directly to JSON without considering lazy proxies — use DTOs or Jackson's Hibernate5Module.
Production Outage: LazyInitializationException After Disabling OSIV
Timeline
- 09:15Team deploys a performance optimization: disables OpenSessionInView (spring.jpa.open-in-view=false) to reduce DB connection hold time.
- 09:22PagerDuty alert: /api/orders endpoint returns 500 errors. Error: LazyInitializationException on Customer.orders.
- 09:25Quick check: the endpoint returns Order entities with a Customer reference. The Customer has a lazy @OneToMany for orders.
- 09:30Engineer re-enables OSIV in staging and the error disappears. But team suspects this is a mask, not a fix.
- 09:45Team inspects the OrderService.getOrders(): it fetches orders with a JOIN FETCH on order items, but the Customer entity is fetched separately via lazy proxy.
- 10:00Engineer identifies that Jackson serialization triggers customer.getOrders() after the transaction commits.
- 10:15Fix: modify the service method to return a DTO that includes only necessary customer fields, avoiding the lazy collection.
- 10:30Deploy fix to production. Monitoring shows no further LazyInitializationException and connection pool usage drops 40%.
We had been running with OSIV enabled for years. The application was mostly CRUD, and no one complained about performance. Then we started scaling: more users, more connections. Our connection pool hit max active during peak hours. Quick investigation showed that OSIV was holding DB connections until the HTTP response was fully written (including view rendering). That was the bottleneck. We decided to disable OSIV as a quick win. Deployed to production. Five minutes later, PagerDuty blew up.
The error was classic: LazyInitializationException on Customer.orders. Our OrderService returned a list of Order entities. Each Order had a Customer reference. Customer had a @OneToMany(mappedBy = 'customer') List<Order> orders. We never needed those orders in the JSON response — but Jackson, when serializing the Customer, called getOrders(). With OSIV off, the session was closed after the transaction in the service method ended. The proxy couldn't initialize. The fix: we created a CustomerDTO with only the fields we needed (name, email). We changed the query to use a JPQL constructor expression or MapStruct. No more lazy load.
Lesson learned: OSIV is a band-aid. The real fix is to never expose entities to the view layer. We now enforce DTOs for all API responses. We also added a custom Jackson module that throws a clear error if a lazy proxy is serialized (instead of the cryptic LazyInitializationException). And we monitor connection pool usage with a custom metric. Since then, zero lazy loading issues.
Root cause
Jackson serialization triggered a lazy collection access on a detached entity after the Hibernate session was closed, due to OSIV being disabled.
The fix
Returned DTOs instead of entities from the service layer, avoiding lazy proxy exposure. Also added a Jackson mix-in to ignore lazy fields.
The lesson
Never rely on OSIV for production. Always use DTOs or projections to control exactly what data leaves the service layer. Lazy loading is for transactional boundaries only.
When you fetch an entity with fetch=FetchType.LAZY, Hibernate returns a proxy object (or a PersistentBag/PersistentSet for collections). The proxy has no data — it just knows the entity's primary key. The first time you call a getter on the proxy, it checks if the Hibernate Session is still open. If yes, it executes a SQL query to load the data. If no, it throws LazyInitializationException.
The session is typically opened when a transaction starts (via @Transactional or manually) and closed when the transaction ends. However, with OpenSessionInView (OSIV), the session is kept open until the HTTP response is committed, allowing lazy loads in the view. But OSIV holds a database connection for the entire duration, which can cause connection pool exhaustion under high load. Spring Boot 2.0 changed the default to true (OSIV enabled), but many teams disable it for performance.
The most common non-obvious cause of LazyInitializationException is serialization. When you return an entity from a REST controller, frameworks like Jackson serialize it by calling all getters. If an entity has a lazy association, calling the getter triggers the lazy load. If the session is closed (transaction ended, OSIV off), you get the exception.
Jackson's Hibernate5Module can help by ignoring lazy proxies or serializing them as null. But that can hide bugs where you actually need the data. Better practice: use DTOs and map entities only after ensuring all needed data is fetched within the transaction. For MVC applications with Thymeleaf, the same issue occurs: the template engine calls getters, and if the session is closed, exception is thrown. Use Spring's @ModelAttribute with caution.
LazyInitializationException often indicates a transaction boundary issue. The typical pattern: a controller calls a service method that returns an entity. The service method has @Transactional, so the session is open during the method. But after the method returns, the transaction commits and the session closes. The controller then accesses a lazy association (e.g., calling entity.getOrders() in a view), causing the error.
The fix is to ensure that any lazy association access happens inside a transaction. This can be done by either (1) moving the access into the service method (e.g., initialize the collection with a JOIN FETCH), (2) using OpenSessionInView, or (3) using a DTO that contains the data you need. Also note that @Transactional works only on public methods called from outside the class — calling a private @Transactional method from the same class won't start a transaction.
When you pass an entity to another thread (e.g., via @Async or a CompletableFuture), the original session is tied to the original thread. The new thread has no session, so accessing lazy data there causes LazyInitializationException. This is common in batch jobs that fetch entities in a transaction and then process them in parallel.
Solution: fetch all necessary data within the transaction before handing off to the async thread. Use DTOs or arrays of primitive values. Alternatively, you can open a new transaction in the async method and re-fetch the entity by ID. Avoid using the Hibernate Session across threads — it's not thread-safe.
Frequently asked questions
Why does LazyInitializationException happen only in production and not in development?
In development, you might have OpenSessionInView enabled by default (Spring Boot 2.0+). Also, development environments have lower concurrency, so connection pool exhaustion is less likely. In production, you might disable OSIV for performance, or the error occurs under load when transactions are shorter. Also, serialization behavior might differ (e.g., different Jackson versions).
Is it safe to set hibernate.enable_lazy_load_no_trans=true?
Technically it works, but it's a terrible idea for production. This setting creates a new Hibernate session for each lazy load, leading to N+1 queries. It also bypasses transaction management, so changes might not be saved. It's a debugging crutch, not a fix. Use it only temporarily to confirm the issue is lazy loading, then implement a proper solution like DTOs.
What is the difference between OpenSessionInView and hibernate.enable_lazy_load_no_trans?
OpenSessionInView (OSIV) keeps the Hibernate session open for the entire HTTP request, allowing lazy loads in the view. It holds a database connection until the response is committed. hibernate.enable_lazy_load_no_trans opens a new session for each individual lazy load, without holding a connection across the whole request. Both can mask design issues and cause performance problems. OSIV is generally preferred over the latter because it at least reuses the same session, but DTOs are the best approach.
Can I use Jackson's @JsonIgnore to fix LazyInitializationException?
Yes, annotating lazy association getters with @JsonIgnore prevents Jackson from calling them, thus avoiding the lazy load. However, this is a workaround — if you later need that data in the response, you'll have to fetch it explicitly. It's better to use DTOs that include exactly the fields you need. You can also use Jackson's Hibernate5Module which serializes uninitialized proxies as null without triggering the load.
Why does @Transactional not work on private methods?
Spring uses AOP proxies to intercept method calls and start/commit transactions. Proxies only intercept external calls — i.e., calls from another bean or from the proxy itself (self-invocation). When you call a private method within the same class, it bypasses the proxy, so no transaction is started. Always put @Transactional on public methods and call them from outside the class (or use self-injection).