If you’ve ever dealt with lazy loading issues, N+1 query nightmares, or mysteriously open database connections in your Spring Boot application, you’ve likely encountered the notorious Open Session in View (OSIV) setting. It’s a seemingly harmless configuration, but it hides a number of critical implications—ones that can quietly erode your application’s scalability and data access boundaries.
In this post, I want to share my personal experience of dealing with OSIV in production, how I came to understand its inner workings, and why I eventually made the decision to disable OSIV in all my Spring Boot projects. I’ll also cover how disabling it led to cleaner architecture, better performance, and fewer late-night debugging sessions.
What is OSIV and Why Is It There?
OSIV stands for Open Session in View. When enabled (which it is by default in Spring Boot), it keeps the Hibernate Session (or JPA EntityManager) open for the entire HTTP request-response lifecycle—not just during the service or repository layer.
What this means is that even after your service logic finishes executing, your view layer (like Thymeleaf or JSON serialization) can still lazily fetch associations from your entities. On the surface, this sounds convenient—it avoids LazyInitializationException when your view tries to access uninitialized relationships.
But this convenience comes at a cost.
The Hidden Costs of Leaving OSIV Enabled
In my early days as a full-stack developer, I appreciated the “magic” of lazy loading in views. I thought it was elegant: you could just reference user.getOrders() in a DTO or template, and everything worked—even if you didn’t explicitly fetch orders in your service. But as my applications grew, I began noticing the symptoms:
- Database connection pool exhaustion under high traffic.
- Unexpected N+1 queries triggered from the controller or serialization layer.
- Hard-to-trace bugs caused by lazy loading from outside of transactional contexts.
- Architecture violations, where controllers indirectly relied on repositories due to lazy loading.
The worst part? These problems often didn’t show up in local development or small-scale test environments. They emerged under stress—during load testing or, worse, in production.
After reading more about the root cause, I realized these were all side effects of OSIV keeping the persistence context alive too long.
Disabling OSIV: A Turning Point
The turning point came when I read a post similar to the one on Maeil Mail discussing why disabling OSIV is recommended in most real-world applications. It finally clicked: having a long-lived persistence context tied to HTTP requests was fundamentally flawed, especially in a layered architecture.
Here’s how I disabled OSIV in application.yml:
That simple line changed everything.
At first, yes—it broke things. I started getting LazyInitializationExceptions in places I didn’t expect. But instead of treating them as errors, I treated them as signals—warnings that my architecture was leaking persistence logic into the wrong layers.
The Benefits of Turning OSIV Off
After refactoring my code to preload necessary associations within service methods (using fetch joins or DTO projections), several benefits became clear:
- Improved performance: I had tighter control over which queries were run and when.
- Reduced N+1 queries: Because I was explicitly deciding which entities to load.
- Clearer separation of concerns: My controllers no longer made assumptions about what was lazily available.
- Better resource management: Database sessions and connections were shorter-lived and easier to manage.
One unexpected side effect? Onboarding became easier. Junior developers didn’t have to debug confusing lazy loading issues—they saw them as compile-time or immediate runtime errors in development, not mysterious bugs in production.
Best Practices After Disabling OSIV
To make life easier after turning OSIV off, here are a few best practices I follow:
- Use DTOs instead of exposing entities directly to the view layer.
- Fetch related entities using JPQL fetch joins or Spring Data Projections.
- Test API responses thoroughly to ensure all needed data is loaded beforehand.
- Be explicit about transaction boundaries—especially in service layers.
- Log SQL queries in dev environments to spot inefficiencies early.
Conclusion: Embrace the Pain Now to Avoid Bigger Pain Later
Disabling OSIV can be painful at first, especially if your project has grown reliant on lazy loading everywhere. But in the long run, it’s one of the best decisions I’ve made for application maintainability and performance.
Open Session in View is a crutch—a temporary fix for poor data access planning. Disabling it forces you to write cleaner, more intentional code. And trust me: once you make the switch and get past the initial friction, you won’t want to go back.
