Question
Hibernate 6.2 Connection Pool Transition and External Provider Requirements
Mira Dey
0 reputation · 22 Aug 2020, 15:08 UTC
72.7K views1
Loading…
0 reputation · 22 Aug 2020, 15:08 UTC
Hibernate 6.2 has removed its built-in connection pool, shifting the responsibility of connection management entirely to external providers such as HikariCP or C3P0. In environments utilizing Spring Boot 3.0, HikariCP is provided by default, but its default configuration may not align with the concurrency requirements of high-throughput applications.
When migrating to Hibernate 6.2, the absence of a fallback pool means that any misconfiguration in the external provider—specifically regarding maximumPoolSize or idleTimeout—can lead to intermittent connection exhaustion. While the SessionFactory may log warnings if no pool is detected, these logs do not prevent runtime timeouts during peak loads.
There is currently uncertainty regarding the long-term architectural roadmap for connection management within the Hibernate 6.x release cycle.
35275 reputation · 22 Aug 2020, 21:28 UTC
Hibernate 6.2 requires an external connection provider. Hibernate ORM 6.0 removed the legacy built-in pool, so hibernate.connection.pool_size is ignored and DriverManagerConnectionProviderImpl is not a supported production provider in 6.x. You must supply a JDBC DataSource or an explicit ConnectionProvider at SessionFactory bootstrap. Spring Boot 3.x provides HikariCP by default; standalone Hibernate requires you to configure HikariCP or C3P0 yourself.
Will Hibernate keep this requirement for all future 6.x versions? The likely answer is yes, but it is not a published roadmap guarantee. Is a lightweight built-in pool planned? No confirmed mechanism exists for the 6.x line. Treat both statements as architectural direction subject to Hibernate governance changes.
hibernate
norgDataSource with Hibernate 6.x.hibernate.connection.pool_size and related legacy pool properties.DataSource bean. In Spring Boot, use spring.datasource.hikari.* properties; in standalone Hibernate, register HikariCP or C3P0 as the ConnectionProvider.maximumPoolSize and idleTimeout for your concurrency target, then validate under load rather than at startup alone.SessionFactory bootstrap completes without missing-provider warnings.Run a read-only dependency check:
./mvnw dependency:tree | grep -i hikariFor Gradle:
./gradlew dependencies --configuration runtimeClasspath | grep -i HikariCPThen bootstrap a test application with no explicit pool and observe whether SessionFactory creation fails or falls back to an unsupported provider. Verify these claims against the official Hibernate ORM 6.2 migration guide before production use.
One missing detail changes these steps: are you bootstrapping through Spring Boot 3.x auto-configuration, or creating SessionFactory standalone?
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 23 Aug 2020, 02:11 UTC
Spring Boot 3.x auto-configures HikariCP with a default maximumPoolSize of 10, which differs from Hibernate 5.x’s built-in pool default of 20 connections. This mismatch often surfaces only under load. To confirm the active pool size without relying on startup logs, inspect the DataSource bean directly:
@Autowired
DataSource dataSource;
public void logPoolConfig() {
if (dataSource instanceof HikariDataSource hikari) {
log.info("Hikari max pool size: {}", hikari.getMaximumPoolSize());
log.info("Hikari idle timeout (ms): {}", hikari.getIdleTimeout());
}
}Additionally, enable HikariCP’s MBeans (spring.datasource.hikari.register-mbeans=true) and query com.zaxxer.hikari:type=Pool via JMX for live metrics. This avoids guesswork when tuning for high-throughput scenarios.