JDBC Connection Pooling — Why It Matters

Direct Answer

A connection pool owns reusable physical database connections and exposes logical Connection handles through a DataSource. Borrowing avoids repeated setup and limits concurrent sessions. Calling close on the logical handle normally resets/returns it. Pooling improves resource management and throughput for many workloads, but results depend on transaction length, SQL latency, database capacity, and correct sizing.

Code Example

HikariConfig cfg = new HikariConfig();
cfg.setJdbcUrl("jdbc:mysql://localhost:3306/shop");
cfg.setUsername("app");
cfg.setPassword(System.getenv("DB_PASS"));   // never hard-code
cfg.setMaximumPoolSize(10);          // bounded connections
cfg.setConnectionTimeout(30000);     // wait up to 30s for a free one
DataSource ds = new HikariDataSource(cfg);

try (Connection con = ds.getConnection()) {  // borrow from pool
    // ... use it ...
}                                             // returned to pool, not destroyed

In Spring Boot you just set spring.datasource.* and get a HikariCP pool automatically.

Common Mistakes & Pitfalls

Opening a new connection per request or per query, which kills performance and can overwhelm the database with connections.