If your app thinks opening a new database connection for every request is clever then this tutorial is here to break that habit. We will walk through setting up JDBC connection pooling with HikariCP for Microsoft SQL Server and show how to stop starving your database and your users at the same time.

Add dependencies and the JDBC driver

Use your build tool to include HikariCP and the Microsoft JDBC driver for SQL Server. If you use Spring Boot add the HikariCP starter so the framework wires things up for you. Do not commit sample URLs with credentials into a repo unless you enjoy explaining to your boss why production leaked secrets are cool.

Create and configure the HikariDataSource

Instantiate a HikariDataSource or declare it as a bean so the framework can manage its lifecycle. Set the basics like driverClassName, username, password, maximumPoolSize and connectionTimeout. The important part is to prefer a framework managed DataSource over a global singleton so shutdown and health checks actually behave.

Configuration checklist

• driverClassName and jdbcUrl set to your SQL Server connection
• username and password pulled from secure config or vault
• maximumPoolSize tuned to realistic concurrency
• connectionTimeout and validationTimeout set so stuck threads fail fast
• minimumIdle set to avoid cold starts if your workload needs it

Use the DataSource in application code

Stop calling DriverManager directly. Obtain connections from the DataSource with getConnection. When you call close on that Connection you are returning it to the pool and not killing the underlying TCP link. That behavior is the whole point of connection pooling and also the reason your app will stop behaving like it is reinventing fire.

Tune the pool and enable monitoring

Start conservative with max pool size and min idle then observe actual throughput and latency. HikariCP exposes MBeans and can be integrated with Micrometer or Prometheus for metrics. Monitor connection usage, active connections, waiting threads and connection creation rates. If you see a lot of connection wait time you either need more pool capacity or you have long running queries that need fixing.

What to watch

• connection wait time during peak traffic
• active connections vs max pool size
• connection creation spikes which mean the pool is constantly growing
• open transactions that hold connections for too long

Test under load and measure results

Run realistic load tests and measure latency and connection metrics. Look for connection leaks and threads waiting for connections. If the database shows slow queries fix them first. Increasing pool size is a band aid that hides problems and makes the database angrier.

Quick troubleshooting tips

• If connections exhaust quickly check for leaks and unclosed resources
• If latency spikes correlate with high active connections inspect long running queries
• If the pool keeps growing set sensible maximumPoolSize and enable leakDetectionThreshold for debugging

In short, HikariCP plus a proper DataSource pattern gives you better resource use and faster responses with Microsoft SQL Server. Tune and monitor rather than guessing, and your app will thank you by not timing out the user who was only trying to click one button.