skip to content

What is Open-Session-In-View (OSIV), is it on by default in Spring Boot, and what are its trade-offs?

level: middleimportance: must knowfreq 72%

answer

  1. Session open for whole request, not just tx
  2. spring.jpa.open-in-view=true by default
  3. OpenEntityManagerInViewInterceptor
  4. holds connection through serialization
  5. hides N+1, lazy loads in auto-commit

basics

~20 s

OSIV keeps the Hibernate session open for the entire HTTP request, so lazy loading still works while the response is being serialized. Spring Boot enables it by default. The downside is it holds the database connection longer and can hide N+1 query problems.

solid answer

~40 s

Open-Session-In-View keeps a single Hibernate Session / EntityManager open for the whole web request, not just the service transaction. Spring Boot enables it by default via spring.jpa.open-in-view=true, implemented by OpenEntityManagerInViewInterceptor. Because the persistence context lives until the response is written, lazy associations can still be initialized during view rendering or JSON serialization — so LazyInitializationException disappears. The trade-offs: the database connection (or at least the EntityManager) is held for the full request including view rendering, hurting connection-pool throughput under load; lazy loads during serialization run outside any transaction in auto-commit mode; and it silently masks N+1 query problems since every proxy access just works. Spring Boot even logs a warning about this at startup. Many teams disable it and fetch explicitly at the boundary.

code

properties · 8 lines
properties
# application.properties
# Default is true in Spring Boot; disabling forces explicit fetching at the boundary
spring.jpa.open-in-view=false

# Startup warning you see when it is left enabled:
# JpaBaseConfiguration :
#   spring.jpa.open-in-view is enabled by default.
#   Therefore, database queries may be performed during view rendering.

go deeper

for a junior

Knows OSIV makes lazy loading work during serialization and is Spring Boot's default.

for a middle

Must state the property/default and articulate the connection-holding and N+1-hiding trade-offs.

for a senior

Distinguishes Session-open vs transaction-open, notes auto-commit lazy loads, and recommends disabling with explicit fetching for APIs.

for a principal

Sets an org-wide policy, weighs throughput/pool sizing, and ties OSIV to layering/boundary discipline.

## What OSIV is **Open-Session-In-View** is a pattern where the JPA persistence context (Hibernate **Session** / **EntityManager**) is bound to the thread for the **entire HTTP request lifecycle** — from the moment the request enters until the response is fully written — rather than only for the duration of a service-layer `@Transactional` method. Because the Session stays open through **view rendering and HTTP-response serialization**, any lazy association accessed by the template engine or by Jackson can still be initialized. Result: `LazyInitializationException` effectively goes away without you doing anything. ## How Spring implements it - Web MVC: `OpenEntityManagerInViewInterceptor` (registered automatically) or the older `OpenEntityManagerInViewFilter` / `OpenSessionInViewFilter`. - It opens the `EntityManager` early and binds it via `TransactionSynchronizationManager`, then closes it after the view is rendered. ## It is ON by default in Spring Boot The property is `spring.jpa.open-in-view`, default **true**. Spring Boot's `JpaBaseConfiguration` logs a warning at startup: > "spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning." That warning exists specifically to make you make a conscious choice. ## The trade-offs **Pros** - Convenience: lazy loading "just works" anywhere in the request; no LazyInitializationException. - Less boilerplate for simple CRUD/view apps. **Cons** - **Connection / EntityManager held longer**: the persistence context spans the whole request including the potentially slow serialization/rendering phase. Under load this ties up resources and reduces effective throughput. - **Lazy loads run outside a transaction**: once the service transaction has committed, additional lazy SELECTs during serialization execute in **auto-commit** mode — each is its own round trip, and they are not part of the original atomic unit of work. - **Hides N+1 problems**: serializing a list where each element lazily loads a child fires one query per element, invisibly. Because nothing throws, the problem only shows up as latency in production. - **Blurs the boundary**: the persistence layer leaks into the presentation layer; you lose an explicit signal of what data a use case actually needs. ## Disabling it Set `spring.jpa.open-in-view=false`. Then you must fetch everything the response needs **inside** the transaction — via `JOIN FETCH`, `@EntityGraph`, or (best) mapping to DTOs. This surfaces N+1 issues at development time as LazyInitializationExceptions, which is often considered a *feature*: it forces explicit, intentional fetching. ## When each choice makes sense - Keep OSIV: small apps, server-side templated views, prototypes, teams that value convenience over tuning. - Disable OSIV: high-throughput APIs, teams enforcing DTO boundaries, anywhere connection-pool efficiency and query visibility matter.

  • If OSIV is disabled, what breaks and how do you fix it?
    Any code that touches a lazy association during serialization/view rendering throws LazyInitializationException. Fix by fetching inside the transaction: JOIN FETCH, @EntityGraph, or mapping to a DTO before returning from the @Transactional method.
  • Under OSIV, are lazy loads during serialization transactional?
    No. Once the service transaction has committed and the Session is still open only via OSIV, subsequent lazy SELECTs run in auto-commit mode outside any transaction — one connection round trip each, not part of an atomic unit of work.

saying these in an interview costs you the question

  • Claiming OSIV is off by default in Spring Boot (it is on)
  • Saying OSIV keeps a transaction open for the whole request (it keeps the Session/EntityManager open, not a transaction)
  • Treating OSIV as a pure win with no cost
  • Not knowing it hides N+1 problems

context

resolving links…