Introduction

When database connections die after a few hours in a Spring Boot JPA or Hibernate application, the problem is usually not Hibernate itself. It is almost always a mismatch between the connection pool lifecycle and something outside the application, such as the database server, load balancer, firewall, or cloud network idle timeout. The practical fix is to align HikariCP settings with the shortest external timeout in the path.

Start with the Timeout Chain

A pooled database connection can be dropped by several layers:

• the database server's idle timeout
• a proxy such as PgBouncer or RDS Proxy
• a firewall or load balancer idle timeout
• the application's own pool lifecycle settings

If an external layer closes a connection first, the pool may hand out a dead connection later unless it has already retired or refreshed it.

That is why the right question is not just "what is Spring Boot doing." The right question is "which layer closes the connection first."

HikariCP Settings Usually Control the Outcome

Spring Boot uses HikariCP by default in modern versions. The important settings are often:

• 'maxLifetime'
• 'idleTimeout'
• 'connectionTimeout'
• 'keepaliveTime'

A common defensive pattern is making maxLifetime slightly shorter than the database or network timeout.

1spring.datasource.hikari.maxLifetime=1740000
2spring.datasource.hikari.idleTimeout=600000
3spring.datasource.hikari.keepaliveTime=300000
4spring.datasource.hikari.connectionTimeout=30000

For example, if an external component kills idle connections after 30 minutes, setting maxLifetime below that helps the pool retire them first.

Dead Connections Often Appear Only After Idle Periods

This is why the issue may show up after four hours, eight hours, or overnight rather than immediately at startup. The app works until the pool reuses a connection that looked fine locally but was already killed remotely.

That reuse pattern makes the bug feel random even though it is usually deterministic with respect to idle time.

If the failure happens after long quiet periods, suspect timeouts before you suspect query logic.

Check Database and Infrastructure Idle Timeouts Explicitly

Examples of things to inspect:

• MySQL wait_timeout
• PostgreSQL idle termination policies or proxies
• cloud load balancer idle timeout
• corporate firewall or NAT timeouts

The shortest timeout in the whole path is usually the one that matters most. Your pool configuration should be designed around that limit.

Without those external numbers, Hikari tuning becomes guesswork.

Validation and Keepalive Can Help

HikariCP generally manages connection validation internally, but keepaliveTime can help keep connections from going stale in environments that aggressively drop idle sessions.

spring.datasource.hikari.keepaliveTime=300000

This is not a substitute for correct lifetime alignment, but it can reduce surprise failures in long-lived services with bursty traffic.

The goal is to avoid handing out a connection that was silently killed by another layer.

Hibernate and JPA Are Usually Not the Root Cause

The exception often surfaces through Hibernate or JPA because that is where the connection is first used after going stale. That does not mean JPA caused it. The ORM is just the place where the dead connection becomes visible.

This distinction is important because it keeps you from debugging entity mappings or transaction annotations when the real issue is connection lifecycle.

Common Pitfalls

• Blaming Hibernate for dead connections that were actually closed by the database or network path.
• Leaving Hikari maxLifetime longer than an external idle timeout.
• Tuning pool values without first identifying the shortest timeout outside the application.
• Ignoring the pattern that failures happen after idle periods rather than during active load.
• Treating a stale-connection problem as if it were a query or transaction bug.

Summary

• Long-lived connection failures in Spring Boot usually come from timeout mismatches, not from JPA itself.
• HikariCP settings should be aligned to retire connections before external layers kill them.
• The shortest timeout in the database, proxy, or network path usually determines the correct tuning target.
• 'keepaliveTime can help in environments that drop idle sessions aggressively.'
• Diagnose the timeout chain first; only then adjust the pool settings deliberately.