Spring Boot JPA — Why OSIV Killed Your Connection Pool (and How to Fix It)

If you've ever seen java.sql.SQLTransientConnectionException or HikariPool-1 - Connection is not available, request timed out after 30000ms, welcome to the club. I've debugged this exact issue at 2 AM on a Black Friday for a payment-processing platform handling 50,000 requests per minute. The root cause? A single property: spring.jpa.open-in-view=true.

Open Session in View (OSIV) is a pattern where the JPA EntityManager (or Hibernate Session) is kept open for the entire duration of a web request. Spring Boot enabled this by default in versions 2.x and earlier because it makes lazy loading transparent — you can access lazy associations in your view layer (JSP, Thymeleaf) without worrying about LazyInitializationException. But this convenience comes at a brutal cost: every HTTP request holds a database connection from the moment the transaction starts until the response is serialized. In a high-throughput SaaS billing system, that means your 100-connection HikariCP pool can handle only a fraction of the concurrent requests it should.

In this article, I'll show you exactly how OSIV kills your connection pool, how to detect it with metrics and logs, and the step-by-step migration to disable it safely. We'll cover real code, production incidents, and the patterns you need to replace lazy loading. By the end, you'll never look at spring.jpa.open-in-view the same way again.

What Is OSIV and Why Does Spring Boot Enable It by Default?

Open Session in View (OSIV) is a design pattern where the Hibernate Session (and its underlying JDBC connection) remains open for the entire duration of an HTTP request. In Spring Boot, this is implemented via the OpenEntityManagerInViewInterceptor or OpenSessionInViewInterceptor. The default behavior in Spring Boot 2.x and 3.x (until you change it) is to enable OSIV.

Why would Spring Boot do this? The answer is simple: backward compatibility with legacy web applications that use JSP, Thymeleaf, or other server-side view technologies. In those applications, the view layer often accesses lazy-loaded entity associations after the service layer has returned. Without OSIV, you'd get a LazyInitializationException because the Hibernate Session is closed when the transaction ends. OSIV keeps the session open so the view can lazily load data without explicit queries.

But here's the problem: in modern REST APIs, you don't have a view layer. You return JSON via Jackson. And Jackson serialization happens in the HTTP response phase, which is after the service layer transaction has committed. With OSIV, the Hibernate Session is still open during JSON serialization. If your entity has lazy associations, Jackson will trigger lazy loads during serialization — each of which requires a database query on the same connection. This means your connection is held for the entire request lifecycle, including network I/O for serialization.

// This is what Spring Boot does by default (2.x and 3.x)
// application.properties
spring.jpa.open-in-view=true  // default

// A typical controller
@RestController
public class UserController {
    @GetMapping("/users/{id}")
    public User getUser(@PathVariable Long id) {
        // Service method with @Transactional
        User user = userService.findById(id);
        // At this point, transaction is committed, but Session is still open
        // Jackson will serialize User, and if User has lazy-loaded 'orders',
        // it triggers a SELECT on the same connection
        return user;
    }
}

What the Official Docs Won't Tell You

The official Spring Boot documentation mentions spring.jpa.open-in-view in a single sentence: "By default, Spring Boot enables the Open EntityManager in View pattern." That's it. No warning about connection pooling. No guidance on when to disable it. No explanation of the trade-offs.

What the docs don't tell you:

1. OSIV turns every HTTP request into a long-lived database transaction. Even if your actual database work takes 5ms, the connection is held for the entire request (often 100-500ms). Under load, this means your connection pool is effectively 10-100x smaller than you think.
2. OSIV masks lazy loading issues. When you disable OSIV, you'll immediately see LazyInitializationException everywhere. This is a good thing — it forces you to write explicit fetch queries instead of relying on lazy loading in the view layer. Lazy loading in a REST API is almost always a code smell.
3. OSIV interacts badly with HikariCP's connection timeout. If your pool is exhausted, requests queue up waiting for a connection. With OSIV, each request holds a connection longer, so the queue grows faster. This creates a positive feedback loop that can bring down your entire application.
4. OSIV bypasses your transaction boundaries. The Hibernate Session is kept open even after @Transactional methods return. This means any lazy load triggered during serialization is not part of the original transaction — it's a separate, auto-committed query. This can lead to inconsistent reads or N+1 queries without you realizing it.

// Add these metrics to detect OSIV issues in production
// Requires spring-boot-starter-actuator and micrometer-registry-prometheus

@Configuration
public class HikariMetricsConfig {
    @Bean
    public MeterBinder hikariMetrics(HikariDataSource dataSource) {
        return new HikariDataSourceMetricsBinder(dataSource);
    }
}

// Then in Prometheus, track:
// - hikaricp_connections_active: should drop to near 0 between requests
// - hikaricp_connections_pending: should be 0 most of the time
// - http_server_requests_seconds_max: compare to DB query duration

// If active connections stay high for the duration of HTTP requests,
// OSIV is likely holding them open.

Step-by-Step: How to Disable OSIV Safely

Disabling OSIV is a one-line config change, but it will break your application if you have lazy-loaded entities anywhere in your REST controllers. Here's the safe migration path:

Step 1: Add the configuration. Set spring.jpa.open-in-view=false in your application.properties or application.yml. This tells Spring Boot not to open a Hibernate Session for the entire request.

Step 2: Run your test suite. You'll likely see LazyInitializationException for any endpoint that returns entities with lazy associations. This is expected and desired.

Step 3: Fix each failing endpoint. There are three approaches: - Use @Transactional on the service method that loads the data. This keeps the session open for the duration of the method, but not the entire HTTP request. - Use JPQL fetch joins to eagerly load the required associations in the query itself. - Use DTOs (Data Transfer Objects) to avoid exposing entities directly. This is the cleanest approach for REST APIs.

Step 4: Test under load. Use a tool like Gatling or k6 to simulate concurrent requests. Compare the connection pool metrics before and after the change.

Step 5: Monitor in production. Deploy the change gradually (canary release) and watch your hikaricp_connections_active metric. It should drop dramatically.

// Step 1: application.properties
spring.jpa.open-in-view=false

// Step 2: Before (will break after OSIV disabled)
@Entity
public class User {
    @OneToMany(mappedBy = "user", fetch = FetchType.LAZY)
    private List<Order> orders;
}

// Step 3: Fix with fetch join in repository
@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    @Query("SELECT u FROM User u LEFT JOIN FETCH u.orders WHERE u.id = :id")
    Optional<User> findByIdWithOrders(@Param("id") Long id);
}

// Step 3: Alternative — use DTO
public record UserDto(Long id, String name, List<OrderDto> orders) {}

@RestController
public class UserController {
    @GetMapping("/users/{id}")
    public UserDto getUser(@PathVariable Long id) {
        User user = userService.findByIdWithOrders(id);
        return new UserDto(user.getId(), user.getName(),
            user.getOrders().stream().map(o -> new OrderDto(o.getId(), o.getAmount())).toList());
    }
}

Using @Transactional as a Replacement for OSIV

When you disable OSIV, the Hibernate Session closes when the @Transactional method returns. If you need lazy loading within a service method, you can use @Transactional to keep the session open for the duration of that method. This is a better pattern than OSIV because:

1. The session is open only for the service method, not the entire HTTP request.
2. You control exactly when the session is open and closed.
3. You can use read-only transactions (@Transactional(readOnly = true)) for queries, which can be optimized by Hibernate.

However, @Transactional is not a silver bullet. If you use it on a controller method, you're essentially re-introducing OSIV at the controller level. The correct pattern is to use @Transactional on service methods and return fully loaded DTOs or entities.

Here's the key: @Transactional on a service method ensures that all lazy loads within that method happen on the same connection. Once the method returns, the session closes. If you return an entity with lazy associations, the caller (controller) cannot access those associations without a new session. That's why DTOs are preferred — they don't have lazy associations.

@Service
public class UserService {
    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Transactional(readOnly = true)  // Session open only during this method
    public UserDto findById(Long id) {
        User user = userRepository.findById(id)
            .orElseThrow(() -> new UserNotFoundException(id));
        // Lazy loads happen here, within the transaction
        List<OrderDto> orders = user.getOrders().stream()
            .map(o -> new OrderDto(o.getId(), o.getAmount()))
            .toList();
        return new UserDto(user.getId(), user.getName(), orders);
    }
}

// Controller — no @Transactional needed
@RestController
public class UserController {
    @GetMapping("/users/{id}")
    public UserDto getUser(@PathVariable Long id) {
        return userService.findById(id);  // Session already closed when this returns
    }
}

Fetch Joins and @EntityGraph: Eager Loading Without Performance Pitfalls

The cleanest way to avoid lazy loading issues is to load all required data in a single query using fetch joins or @EntityGraph. This eliminates the need for lazy loading entirely and is more performant than N+1 queries.

JPQL Fetch Join: Use LEFT JOIN FETCH or JOIN FETCH in your JPQL query to eagerly load associations. This generates a single SQL query with JOINs, which is efficient for most use cases.

@EntityGraph: A declarative way to define fetch plans. You can define named entity graphs on your entity class and reference them in your repository methods. This is cleaner than raw JPQL for complex fetch strategies.

Important caveat: Fetch joins can cause performance issues if you fetch multiple collections in the same query (cartesian product problem). In that case, use multiple queries or batch fetching.

Here's a real-world example from a SaaS billing system where we needed to load invoices with their line items and payment transactions. Using fetch joins reduced the query count from 100+ to 1.

@Entity
@NamedEntityGraph(name = "User.withOrdersAndPayments",
    attributeNodes = {
        @NamedAttributeNode("orders"),
        @NamedAttributeNode(value = "orders", subgraph = "orders.payments")
    },
    subgraphs = {
        @NamedSubgraph(name = "orders.payments",
            attributeNodes = @NamedAttributeNode("payments"))
    }
)
public class User {
    @OneToMany(mappedBy = "user")
    private List<Order> orders;
}

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    // JPQL fetch join
    @Query("SELECT u FROM User u LEFT JOIN FETCH u.orders WHERE u.id = :id")
    Optional<User> findByIdWithOrders(@Param("id") Long id);

    // Using @EntityGraph
    @EntityGraph(value = "User.withOrdersAndPayments", type = EntityGraphType.FETCH)
    Optional<User> findById(Long id);
}

// Service method — no lazy loading issues
@Transactional(readOnly = true)
public UserDto findById(Long id) {
    User user = userRepository.findById(id)
        .orElseThrow(() -> new UserNotFoundException(id));
    // All associations already loaded — no lazy loads needed
    return UserDto.from(user);
}

Detecting OSIV Issues in Production: Metrics and Logging

How do you know if OSIV is killing your connection pool? You need to monitor the right metrics. Here's what to look for:

1. HikariCP active connections vs. HTTP request duration. If the active connection count remains high for the entire duration of HTTP requests (not just the DB query time), OSIV is likely holding connections open. In Grafana, overlay hikaricp_connections_active with http_server_requests_seconds.

2. Connection pool pending count. If hikaricp_connections_pending is consistently above 0, your pool is exhausted. Check if the active connections correlate with HTTP request duration.

3. Thread dumps. Take thread dumps during peak load. Look for threads in BLOCKED state waiting on HikariPool.getConnection(). Count how many threads are in that state.

4. Slow query log. Enable MySQL's slow query log (set long_query_time = 0 temporarily). If you see many identical queries for lazy-loaded associations, that's the N+1 problem caused by OSIV.

5. Custom actuator endpoint. Create a custom endpoint that exposes the current HikariCP state, including which threads are holding connections.

@Component
@Endpoint(id = "connection-pool-debug")
public class ConnectionPoolDebugEndpoint {
    private final HikariDataSource dataSource;

    public ConnectionPoolDebugEndpoint(HikariDataSource dataSource) {
        this.dataSource = dataSource;
    }

    @ReadOperation
    public Map<String, Object> debug() {
        HikariPoolMXBean poolMXBean = dataSource.getHikariPoolMXBean();
        return Map.of(
            "activeConnections", poolMXBean.getActiveConnections(),
            "idleConnections", poolMXBean.getIdleConnections(),
            "pendingThreads", poolMXBean.getThreadsAwaitingConnection(),
            "totalConnections", poolMXBean.getTotalConnections(),
            "maxPoolSize", dataSource.getMaximumPoolSize()
        );
    }
}

// Access: GET /actuator/connection-pool-debug
// Response: {"activeConnections":48,"idleConnections":2,"pendingThreads":12,...}

Advanced: OSIV with Multiple Data Sources and Read Replicas

OSIV becomes even more problematic when you have multiple data sources (e.g., primary + read replica) or complex routing. Spring Boot's OSIV interceptor applies to the default EntityManagerFactory. If you have multiple @Primary and @Secondary data sources, the interceptor might open sessions on the wrong data source or fail to close them properly.

Scenario: You have a primary data source for writes and a read replica for queries. You configure two DataSource beans and two EntityManagerFactory beans. With OSIV enabled, the interceptor will open a session on the primary data source for every request, even if the request only reads data. This means your read replica is underutilized, and your primary pool is exhausted by read requests.

Fix: Disable OSIV globally (spring.jpa.open-in-view=false) and use @Transactional(readOnly = true) with a routing data source to direct read queries to the replica. Each @Transactional method will open and close its own session on the appropriate data source.

Another issue: With OSIV, lazy loading always uses the original session's data source. If you load an entity from the primary data source and then try to lazy-load an association, it will query the primary again — even if the association could be served from the read replica.

@Configuration
public class DataSourceConfig {
    @Bean
    @Primary
    @ConfigurationProperties("spring.datasource.primary")
    public DataSource primaryDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean
    @ConfigurationProperties("spring.datasource.replica")
    public DataSource replicaDataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean
    public DataSource routingDataSource() {
        RoutingDataSource routing = new RoutingDataSource();
        routing.setDefaultTargetDataSource(primaryDataSource());
        Map<Object, Object> targets = new HashMap<>();
        targets.put("PRIMARY", primaryDataSource());
        targets.put("REPLICA", replicaDataSource());
        routing.setTargetDataSources(targets);
        return routing;
    }

    // With OSIV disabled, @Transactional(readOnly = true) will route to replica
    // and open/close session per method, not per request
}

Testing Your Fix: Load Testing and Validation

After disabling OSIV and fixing lazy loading issues, you need to validate the changes under load. Here's a testing strategy:

1. Unit tests. Ensure each repository method with fetch joins returns the correct data. Test that LazyInitializationException is not thrown in service methods with @Transactional.

2. Integration tests. Use @SpringBootTest with a real database (or Testcontainers) to test full request flows. Disable OSIV in the test profile and verify that endpoints return correct responses.

3. Load testing. Use Gatling or k6 to simulate production traffic. Measure: - Throughput (requests per second) - P50, P95, P99 latency - Connection pool metrics (active, pending, idle) - Error rate (should be 0%)

4. Comparison. Run the same load test with OSIV enabled and disabled. The difference in throughput is usually 5-10x.

5. Gradual rollout. Deploy the change to a canary instance first. Monitor for 24 hours. Then roll out to the rest of the cluster.

Here's a simple k6 script to test your endpoints.

// k6 script (JavaScript, but relevant for Java devs)
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },  // ramp up to 100 users
    { duration: '5m', target: 100 },  // stay at 100 users
    { duration: '2m', target: 0 },    // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(99)<500'],  // 99% of requests under 500ms
    http_req_failed: ['rate<0.01'],    // less than 1% errors
  },
};

export default function () {
  const res = http.get('http://localhost:8080/users/1');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
  });
  sleep(1);
}

// Run: k6 run load-test.js
// Compare results with OSIV enabled vs disabled