JDBC Connection Pooling

Previous Next

Every earlier example on this track opened a connection with DriverManager.getConnection(...) right before using it. That's fine for learning, but it's a bad idea in a real application that serves many requests. This page explains why, and introduces the standard fix: a connection pool.

Why a Raw Connection Per Request Doesn't Scale

Opening a JDBC connection is not free. Every call to DriverManager.getConnection(...) has to:

Step	Cost
TCP handshake	A brand-new network connection to the database server has to be established.
Database authentication	The server verifies credentials and sets up a session for that connection.
Resource setup	The database allocates memory and internal structures for the new session.

Do that on every single request in a web application handling hundreds of requests per second, and the connection setup overhead alone can dwarf the time spent actually running your query.

What a Connection Pool Is

A connection pool is a small, pre-warmed set of database connections that stay open and get reused. Instead of opening and closing a connection per request, your code:

Borrows an already-open connection from the pool.
Uses it to run queries, exactly like any other Connection.
Returns it to the pool by calling close() — which, for a pooled connection, doesn't actually close the socket, it just hands the connection back for the next borrower.

Key idea: with a pool, conn.close() no longer means "disconnect from the database." It means "I'm done with this connection for now — someone else can have it."

HikariCP: The De-Facto Standard

HikariCP is the connection pool almost every modern Java project reaches for. It's small, extremely fast, and is the default connection pool used by Spring Boot when you configure a JDBC data source. Using it in a project means adding it as a dependency (through Maven — see the Maven track, coming soon) and configuring it once at startup.

Example: Setting Up and Using a HikariCP Pool

import com.zaxxer.hikari.HikariConfig;
import com.zaxxer.hikari.HikariDataSource;

// 1) Configure the pool once, at application startup
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://localhost:3306/coding_with_sonu");
config.setUsername("root");
config.setPassword("");
config.setMaximumPoolSize(10);

HikariDataSource ds = new HikariDataSource(config);

// 2) Borrow a connection whenever you need one
try (Connection conn = ds.getConnection()) {
  // use conn like any other JDBC connection
} // close() here returns it to the pool instead of disconnecting

Dependency required: HikariConfig and HikariDataSource come from the HikariCP library, not the JDK. You'll add it to your project through Maven once that track (coming soon) is available.

Where This Fits Later: The Spring Track

This concept becomes even more relevant once you reach the Spring track (coming soon). Spring Boot wires up a HikariCP-backed data source for you automatically from a few configuration properties — you rarely construct HikariConfig by hand in a Spring application. Understanding pooling here means that setup won't feel like magic when you get there.

Next up: CallableStatement shows how to call stored procedures that already live inside the database.

Previous Next