In a banking system with 500–3000 RPS for reads and 50–300 RPS for writes, increasing the HikariCP maximumPoolSize from 10 to 50 per instance caused performance degradation. The database, which previously handled 3000 RPS, struggled due to excessive concurrent connections competing for CPU and shared buffers. The team reduced the pool size to 15, which resolved the latency issues.
On an enterprise platform, a document generation module experienced connection leaks. The @Transactional method held database connections for 30–40 seconds while waiting for a LibreOffice headless conversion process. The issue was resolved by splitting the database operations and the heavy I/O into separate transactions, and by implementing the leak-detection-threshold setting.
A banking environment faced intermittent 'Connection reset' errors caused by a firewall that silently terminated idle TCP connections after 15 minutes. The application pool considered these connections valid for up to 30 minutes. The team fixed this by setting max-lifetime to 600,000 ms (10 minutes) and enabling keepalive-time at 120,000 ms.
When using PgBouncer in transaction pooling mode, server-side prepared statements often fail because the connection to the database changes between transactions. To resolve this, developers can either switch PgBouncer to session mode or disable server-side prepared statements in the JDBC driver by setting prepareThreshold to 0.
