Root Cause Analysis and Solutions for HikariCP Connection Pool Exhaustion

Nov 23, 2025 · Programming · 9 views · 7.8

Keywords: HikariCP | Connection Pool | Transaction Management | Spring Boot | Database Connection

Abstract: This paper provides an in-depth analysis of HikariCP connection pool exhaustion in Spring Boot applications. Through a real-world case study, it reveals connection leakage issues caused by improper transaction management and offers solutions based on @Transactional annotations. The article explains connection pool mechanisms, transaction boundary management importance, and code refactoring techniques to prevent connection resource leaks.

Problem Background and Phenomenon Analysis

In technology stacks based on Spring Boot, Hibernate, and PostgreSQL, development teams frequently encounter connection pool exhaustion issues. The specific manifestation is: after the application runs for several hours, the number of active connections gradually increases to the configured limit, eventually causing java.sql.SQLTransientConnectionException: HikariPool-0 - Connection is not available, request timed out after 30000ms exceptions.

From the error stack trace, it's evident that when all connections in the pool are active and no idle connections are available, new connection requests timeout after waiting for 30 seconds. This situation typically indicates connection leakage or improper transaction management in the application.

Root Cause Investigation

Through in-depth analysis of actual cases, the problem root cause is identified not as a defect in the HikariCP connection pool itself, but rather improper transaction management strategies at the application layer. Specifically:

In REST controllers, certain complex methods execute multiple database operations through JPA Repository interfaces. Due to the lack of unified transaction boundary management, each Repository call may create independent database connections, leading to continuous accumulation of connection counts.

Consider the following example code:

@RestController
public class UserController {
    @Autowired
    private UserRepository userRepository;
    
    @Autowired
    private OrderRepository orderRepository;
    
    public void processUserOrder(Long userId, OrderDTO orderDTO) {
        // First database operation
        User user = userRepository.findById(userId);
        
        // Business logic processing
        user.updateLastLogin();
        
        // Second database operation
        userRepository.save(user);
        
        // Third database operation
        Order order = createOrderFromDTO(orderDTO);
        orderRepository.save(order);
        
        // More database operations...
    }
}

In this implementation, each Repository method call may execute on different database connections, even though they logically belong to the same business operation.

Solution Implementation

Two effective solutions are provided for the above problem:

Solution 1: Using @Transactional Annotation

Add @Transactional annotation to controller methods or service layer methods to ensure the entire business operation executes within the same transaction:

@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;
    
    @Autowired
    private OrderRepository orderRepository;
    
    @Transactional
    public void processUserOrder(Long userId, OrderDTO orderDTO) {
        User user = userRepository.findById(userId);
        user.updateLastLogin();
        userRepository.save(user);
        
        Order order = createOrderFromDTO(orderDTO);
        orderRepository.save(order);
    }
}

Solution 2: Transactional Service Method Encapsulation

Encapsulate complex business logic within single transactional methods at the service layer:

@Service
public class OrderProcessingService {
    
    @Transactional
    public ProcessingResult processCompleteOrder(OrderRequest request) {
        // All database operations execute within the same transaction
        User user = validateAndGetUser(request.getUserId());
        Inventory inventory = checkInventory(request.getProductId());
        Order order = createOrder(user, inventory, request);
        updateInventory(inventory, request.getQuantity());
        
        return buildProcessingResult(order);
    }
}

Technical Principle Deep Analysis

Connection Pool Working Mechanism

HikariCP, as a high-performance connection pool, includes core mechanisms such as:

When transaction boundaries are unclear, connections may not be returned promptly, leading to connection pool resource exhaustion.

Spring Transaction Management

The Spring framework provides declarative transaction management through the @Transactional annotation:

Best Practice Recommendations

Based on practical project experience, the following best practices are summarized:

  1. Clear Transaction Boundaries: Define clear transaction boundaries at the service layer, avoid direct database operations in controllers
  2. Reasonable Connection Pool Configuration: Adjust parameters like maximumPoolSize, connectionTimeout based on application load
  3. Enable Connection Leak Detection: Set leakDetectionThreshold to monitor potential connection leaks
  4. Monitoring and Alerting: Establish monitoring mechanisms for connection pool usage to promptly detect anomalies
  5. Code Review: Regularly review database access code to ensure correctness of transaction management

Conclusion

HikariCP connection pool exhaustion issues often stem from improper transaction management at the application layer, rather than defects in the connection pool itself. By properly using @Transactional annotations and optimizing transaction boundary management, connection leakage problems can be effectively avoided. In actual development, database operations should be encapsulated within unified transactional methods at the service layer to ensure proper management and efficient utilization of connection resources.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.