Connection Pooling - Learning Module

Loading content...

0/273

Connection Pool Implementations

Choosing Your Connection Pool Implementation

Understanding the theory of connection pooling is essential, but implementing it correctly requires knowing your options. Connection pools aren't created equal—they differ dramatically in features, performance, default configurations, and failure modes.

Choosing the right pool implementation, and configuring it correctly, can mean the difference between a system that handles 10,000 requests per second and one that collapses under 1,000. This page surveys the major connection pooling implementations across programming ecosystems, examining their architectures, strengths, and configuration requirements.

What You Will Learn

By the end of this page, you will understand the major connection pool implementations for Java, Python, Node.js, Go, and .NET. You'll learn their architectural differences, recommended configurations, and common pitfalls. You'll be able to choose the right pool for your stack and configure it for production workloads.

Java Connection Pools

Java has the most mature connection pooling ecosystem, with multiple production-grade options. Understanding the landscape helps you choose well.

HikariCP: The Gold Standard

HikariCP (光 - Japanese for "light") is widely considered the fastest and most reliable Java connection pool. It's the default pool in Spring Boot 2.x+ for good reason.

HikariCP Strengths

•Extreme performance — Benchmark-winning connection acquisition times, often measuring in nanoseconds.
•Minimal bytecode — ~130KB with zero external dependencies, reducing attack surface.
•Excellent defaults — Sensible out-of-box configuration; many apps work perfectly with minimal tuning.
•Robust leak detection — Clear warnings when connections aren't returned properly.
•Connection validation — Efficient connection testing without typical overhead.
•Comprehensive metrics — Full JMX and Micrometer integration for observability.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
import com.zaxxer.hikari.HikariConfig;
import com.zaxxer.hikari.HikariDataSource;
 
public class DatabaseConfig {
    public static HikariDataSource createDataSource() {
        HikariConfig config = new HikariConfig();
        
        // Connection settings
        config.setJdbcUrl("jdbc:postgresql://primary.db.internal:5432/myapp");
        config.setUsername(System.getenv("DB_USER"));
        config.setPassword(System.getenv("DB_PASSWORD"));
        config.setDriverClassName("org.postgresql.Driver");
        
        // Pool sizing - start conservative
        config.setMinimumIdle(10);          // Minimum connections to maintain
        config.setMaximumPoolSize(20);      // Maximum connections allowed
        
        // Timeout configuration
        config.setConnectionTimeout(10000);  // 10s to acquire from pool
        config.setIdleTimeout(600000);       // 10 min before closing idle
        config.setMaxLifetime(1800000);      // 30 min maximum connection age
        
        // Validation
        config.setConnectionTestQuery("SELECT 1");
        config.setValidationTimeout(5000);   // 5s validation timeout
        
        // Leak detection (development/staging)
        config.setLeakDetectionThreshold(30000); // 30s warning threshold
        
        // Performance optimizations
        config.addDataSourceProperty("cachePrepStmts", "true");
        config.addDataSourceProperty("prepStmtCacheSize", "250");
        config.addDataSourceProperty("prepStmtCacheSqlLimit", "2048");
        config.addDataSourceProperty("useServerPrepStmts", "true");
        
        // Pool name for monitoring
        config.setPoolName("MyApp-Pool");
        
        return new HikariDataSource(config);
    }
}

Alternatives and when to consider them:

Java Connection Pool Comparison
Pool	Strengths	When to Consider	Cautions
HikariCP	Fastest, smallest, most reliable	Default choice for new projects	None significant—use it
Apache DBCP2	Apache ecosystem, wide adoption	Legacy projects, existing Apache stack	Slower than Hikari, more complex config
c3p0	Mature, well-documented	Hibernate legacy projects	Older design, performance issues at scale
Tomcat JDBC Pool	Tomcat integration, async support	Already using Tomcat, need async	Larger footprint, more configuration
Vibur DBCP	Simple, concurrent	Specific compatibility needs	Less ecosystem support

The Simple Recommendation

For any new Java project in 2024+, use HikariCP. It's faster, simpler, and more reliable than alternatives. Spring Boot made it the default for good reason. Only use alternatives if you have specific legacy constraints.

Python Connection Pools

Python's connection pooling landscape is more fragmented, with different approaches for different database drivers and frameworks.

SQLAlchemy's Built-in Pooling:

SQLAlchemy, the dominant Python ORM, includes sophisticated connection pooling. It's often the right choice when using SQLAlchemy.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
from sqlalchemy import create_engine
from sqlalchemy.pool import QueuePool
 
# Production-grade engine configuration
engine = create_engine(
    "postgresql://user:password@db.example.com:5432/myapp",
    
    # Pool class selection (QueuePool is default and recommended)
    poolclass=QueuePool,
    
    # Pool sizing
    pool_size=10,              # Number of connections to maintain
    max_overflow=20,           # Additional connections during peak load
    # Total max = pool_size + max_overflow = 30 connections
    
    # Timeout configuration
    pool_timeout=10,           # Seconds to wait for connection
    pool_recycle=1800,         # Recreate connections after 30 minutes
    pool_pre_ping=True,        # Validate connections before use
    
    # Connection arguments passed to underlying driver
    connect_args={
        "connect_timeout": 10,
        "application_name": "my-application",
        "options": "-c statement_timeout=30000"  # 30s query timeout
    },
    
    # Echo SQL (development only)
    echo=False,
    
    # Use pessimistic connection validation
    pool_use_lifo=True,        # Use most recently returned connection
)
 
# In application code:
with engine.connect() as conn:
    result = conn.execute(text("SELECT * FROM users WHERE id = :id"), {"id": user_id})
    # Connection automatically returned to pool after 'with' block

SQLAlchemy pool classes:

SQLAlchemy Pool Types
Pool Class	Behavior	Use Case
QueuePool	Thread-safe pool with configurable size	Default—use for most applications
StaticPool	Single connection, shared across threads	In-memory SQLite testing only
NullPool	No pooling—new connection per request	External pooler (PgBouncer) handles pooling
AsyncAdaptedQueuePool	QueuePool for async engines	asyncio-based applications

psycopg2/psycopg3 Native Pooling:

For applications not using SQLAlchemy, the psycopg libraries provide native pooling.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
from psycopg_pool import ConnectionPool
 
# Create pool at application startup
pool = ConnectionPool(
    conninfo="postgresql://user:password@db.example.com:5432/myapp",
    min_size=5,              # Minimum connections
    max_size=20,             # Maximum connections
    max_waiting=50,          # Max requests waiting for connection
    max_idle=300,            # Close idle connections after 5 minutes
    open=True,               # Open connections immediately
    configure=lambda conn: conn.execute(
        "SET statement_timeout = '30s'"
    ),  # Configure each connection
)
 
# Usage with context manager (recommended)
def get_user(user_id: int):
    with pool.connection() as conn:
        with conn.cursor() as cur:
            cur.execute("SELECT * FROM users WHERE id = %s", (user_id,))
            return cur.fetchone()
 
# Explicit check-out/check-in (avoid if possible)
def get_user_explicit(user_id: int):
    conn = pool.getconn()
    try:
        with conn.cursor() as cur:
            cur.execute("SELECT * FROM users WHERE id = %s", (user_id,))
            return cur.fetchone()
    finally:
        pool.putconn(conn)  # Always return connection!
 
# Cleanup at application shutdown
pool.close()

Python GIL Considerations

Python's Global Interpreter Lock (GIL) means true parallelism requires multiple processes. For high-concurrency applications, use asyncio-based pools with async drivers (asyncpg, psycopg async) or run multiple worker processes with smaller per-process pools. A single Python process rarely benefits from more than 5-10 connections.

Node.js Connection Pools

Node.js's single-threaded event loop model makes connection pooling particularly straightforward—but also particularly important. Without pooling, every database call would block other operations waiting for connection establishment.

node-postgres (pg) Pool:

The standard PostgreSQL client for Node.js includes robust pooling.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
const { Pool } = require('pg');
 
// Production pool configuration
const pool = new Pool({
  // Connection details
  host: process.env.DB_HOST,
  port: parseInt(process.env.DB_PORT) || 5432,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  
  // SSL configuration (required for cloud databases)
  ssl: process.env.NODE_ENV === 'production' ? {
    rejectUnauthorized: true,
    ca: fs.readFileSync('/path/to/ca-certificate.crt').toString(),
  } : false,
  
  // Pool sizing
  max: 20,                    // Maximum connections in pool
  min: 5,                     // Minimum connections to maintain
  
  // Timeout configuration
  connectionTimeoutMillis: 10000,  // 10s to establish new connection
  idleTimeoutMillis: 30000,        // 30s before closing idle connection
  
  // Additional options
  allowExitOnIdle: true,      // Allow process to exit when pool is idle
  
  // Application name for monitoring
  application_name: 'my-node-app',
});
 
// Event handling for pool health monitoring
pool.on('connect', (client) => {
  console.log('New client connected to pool');
});
 
pool.on('error', (err, client) => {
  console.error('Unexpected error on idle client', err);
  // Don't exit—pool will handle reconnection
});
 
pool.on('remove', (client) => {
  console.log('Client removed from pool');
});
 
// Query execution (automatic checkout/checkin)
async function getUser(userId) {
  const result = await pool.query(
    'SELECT * FROM users WHERE id = $1',
    [userId]
  );
  return result.rows[0];
}
 
// Transaction with explicit client checkout
async function transferFunds(fromId, toId, amount) {
  const client = await pool.connect();  // Checkout connection
  try {
    await client.query('BEGIN');
    await client.query(
      'UPDATE accounts SET balance = balance - $1 WHERE id = $2',
      [amount, fromId]
    );
    await client.query(
      'UPDATE accounts SET balance = balance + $1 WHERE id = $2',
      [amount, toId]
    );
    await client.query('COMMIT');
  } catch (e) {
    await client.query('ROLLBACK');
    throw e;
  } finally {
    client.release();  // Always release back to pool!
  }
}
 
// Graceful shutdown
process.on('SIGTERM', async () => {
  await pool.end();
  process.exit(0);
});

MySQL (mysql2) Pool:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
const mysql = require('mysql2/promise');
 
// Create connection pool
const pool = mysql.createPool({
  host: process.env.DB_HOST,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_NAME,
  
  // Pool sizing
  connectionLimit: 20,        // Maximum connections
  queueLimit: 100,            // Maximum waiting requests (0 = unlimited)
  
  // Timeout configuration
  connectTimeout: 10000,      // 10s connection timeout
  waitForConnections: true,   // Wait if all connections busy
  
  // Additional options
  enableKeepAlive: true,
  keepAliveInitialDelay: 30000,  // 30s keepalive interval
});
 
// Usage example
async function getUser(userId) {
  const [rows] = await pool.execute(
    'SELECT * FROM users WHERE id = ?',
    [userId]
  );
  return rows[0];
}

Single Process Sizing

Node.js runs on a single thread per process. A pool of 10-20 connections is typically sufficient for a single Node process—the event loop handles concurrency efficiently. For higher throughput, run multiple Node processes (using PM2 cluster mode or Kubernetes pods) with smaller pools per process.

Go Connection Pools

Go's database/sql package includes built-in connection pooling. This is one of Go's strengths—pooling is a first-class, standard library feature rather than a third-party add-on.

database/sql Built-in Pooling:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
package main
 
import (
    "database/sql"
    "time"
    "log"
    
    _ "github.com/lib/pq"  // PostgreSQL driver
)
 
func initDB() (*sql.DB, error) {
    // Open database connection (pool is created automatically)
    connStr := "postgres://user:password@db.example.com:5432/myapp?sslmode=require"
    db, err := sql.Open("postgres", connStr)
    if err != nil {
        return nil, err
    }
    
    // Configure pool (these are the key settings)
    db.SetMaxOpenConns(25)           // Maximum open connections to database
    db.SetMaxIdleConns(10)           // Maximum idle connections in pool
    db.SetConnMaxLifetime(30 * time.Minute)  // Maximum time a connection can be reused
    db.SetConnMaxIdleTime(5 * time.Minute)   // Maximum time a connection can be idle
    
    // Verify connection works
    if err := db.Ping(); err != nil {
        db.Close()
        return nil, err
    }
    
    return db, nil
}
 
func main() {
    db, err := initDB()
    if err != nil {
        log.Fatalf("Failed to initialize database: %v", err)
    }
    defer db.Close()
    
    // Query example (connection automatically managed)
    var name string
    err = db.QueryRow("SELECT name FROM users WHERE id = $1", 1).Scan(&name)
    if err != nil {
        log.Printf("Query failed: %v", err)
    }
    
    // Transaction example
    tx, err := db.Begin()
    if err != nil {
        log.Fatalf("Failed to begin transaction: %v", err)
    }
    
    _, err = tx.Exec("UPDATE accounts SET balance = balance - $1 WHERE id = $2", 100, 1)
    if err != nil {
        tx.Rollback()
        log.Printf("Update failed: %v", err)
        return
    }
    
    _, err = tx.Exec("UPDATE accounts SET balance = balance + $1 WHERE id = $2", 100, 2)
    if err != nil {
        tx.Rollback()
        log.Printf("Update failed: %v", err)
        return
    }
    
    if err := tx.Commit(); err != nil {
        log.Printf("Commit failed: %v", err)
    }
}

Go pool configuration parameters explained:

Go database/sql Pool Settings
Method	Description	Recommended Value
SetMaxOpenConns	Maximum total connections (active + idle)	cores × 2 + 1 (or 20-50)
SetMaxIdleConns	Maximum connections kept idle in pool	Same as MaxOpenConns for fixed pool
SetConnMaxLifetime	Maximum time before connection is recycled	15-30 minutes
SetConnMaxIdleTime	Maximum idle time before connection closes	5-10 minutes

Go's Goroutine Advantage

Go's lightweight goroutines mean you can handle thousands of concurrent requests with a small connection pool. Unlike threads, goroutines are cheap—you don't need a connection per goroutine. A pool of 25 connections can serve thousands of concurrent goroutines efficiently, as most will be waiting on I/O rather than actively using a connection.

Popular Go SQL Libraries:

Library	Type	Pooling	Notes
database/sql	Standard library	Built-in	Use for most applications
sqlx	Extension	Uses database/sql pool	Adds convenience features
pgx	PostgreSQL-specific	Has own pool option	Higher performance for Postgres
GORM	ORM	Wraps database/sql	Convenient but adds overhead

For most Go applications, the standard library database/sql with a driver like lib/pq or pgx provides excellent pooling with minimal configuration.

.NET Connection Pools

.NET (C#/F#) has automatic connection pooling built into ADO.NET. This is both a blessing and a curse—it works out of the box but can cause confusion when developers don't realize pooling is happening.

ADO.NET Automatic Pooling:

When you open a SqlConnection in .NET, you don't get a new database connection—you get a connection from an automatically managed pool. Pooling is controlled via connection string parameters.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// Connection string with explicit pool configuration
string connectionString = 
    "Server=db.example.com;" +
    "Database=myapp;" +
    "User Id=appuser;" +
    "Password=secret;" +
    "Pooling=true;" +               // Enable pooling (default is true)
    "Min Pool Size=5;" +            // Minimum connections to maintain
    "Max Pool Size=20;" +           // Maximum connections allowed
    "Connection Lifetime=1800;" +   // 30 min max lifetime (seconds)
    "Connection Idle Timeout=300;" + // 5 min idle timeout (seconds)
    "Connect Timeout=10;" +         // 10s connection timeout
    "Encrypt=true;" +               // Enable TLS
    "Trust Server Certificate=false;";
 
// For Entity Framework Core
services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString, sqlOptions =>
    {
        sqlOptions.EnableRetryOnFailure(
            maxRetryCount: 3,
            maxRetryDelay: TimeSpan.FromSeconds(30),
            errorNumbersToAdd: null
        );
        sqlOptions.CommandTimeout(30);
    })
);
 
// For Npgsql (PostgreSQL)
string pgConnectionString = 
    "Host=db.example.com;" +
    "Database=myapp;" +
    "Username=appuser;" +
    "Password=secret;" +
    "Pooling=true;" +
    "Minimum Pool Size=5;" +
    "Maximum Pool Size=20;" +
    "Connection Idle Lifetime=300;" +
    "Connection Pruning Interval=10;" +
    "SSL Mode=Require;";

Critical .NET pooling behaviors:

Important .NET Pooling Facts

•Pools are per-connection-string — Different connection strings create separate pools. Be careful with dynamic credentials!
•Pooling is on by default — You don't need to enable it; you need to be aware it exists.
•Using blocks are essential — using (var conn = new SqlConnection(...)) ensures connections return to pool. Forgetting using causes pool exhaustion.
•Async methods recommended — Use OpenAsync(), ExecuteReaderAsync(), etc. for better pool utilization under load.
•Pool exhaustion throws — When pool is full and all connections busy, SqlConnection.Open() blocks until timeout, then throws.
•Connection reset on return — Connections are automatically reset (transaction rolled back, state cleared) when returned to pool.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
public class UserRepository
{
    private readonly string _connectionString;
    
    public UserRepository(IConfiguration config)
    {
        _connectionString = config.GetConnectionString("DefaultConnection");
    }
    
    // Good: Using statement ensures connection return
    public async Task<User> GetUserAsync(int id)
    {
        await using var connection = new SqlConnection(_connectionString);
        await connection.OpenAsync();
        
        var command = new SqlCommand(
            "SELECT Id, Name, Email FROM Users WHERE Id = @Id",
            connection
        );
        command.Parameters.AddWithValue("@Id", id);
        
        await using var reader = await command.ExecuteReaderAsync();
        if (await reader.ReadAsync())
        {
            return new User
            {
                Id = reader.GetInt32(0),
                Name = reader.GetString(1),
                Email = reader.GetString(2)
            };
        }
        return null;
    }
    
    // Bad: Missing using—connection never returns to pool!
    public async Task<User> GetUserBadAsync(int id)
    {
        var connection = new SqlConnection(_connectionString);  // NO USING!
        await connection.OpenAsync();
        // If exception occurs here, connection is orphaned
        // Eventually causes pool exhaustion
        var command = new SqlCommand("...", connection);
        // ... 
        // connection.Close() might never execute
        return new User();
    }
}

The Most Common .NET Pooling Bug

Pool exhaustion in .NET is almost always caused by failing to dispose connections properly. Always use using statements or await using for async code. Entity Framework handles this automatically, but raw ADO.NET requires explicit connection lifecycle management.

ORM Integration Patterns

Most production applications use Object-Relational Mappers (ORMs) rather than raw SQL. Understanding how ORMs interact with connection pools is essential for correct configuration.

Django ORM (Python):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# settings.py
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'myapp',
        'USER': 'appuser',
        'PASSWORD': os.environ['DB_PASSWORD'],
        'HOST': 'db.example.com',
        'PORT': '5432',
        
        # Connection persistence
        'CONN_MAX_AGE': 600,      # Keep connections for 10 minutes
        # Set to None for unlimited (use with caution)
        # Set to 0 for connect-per-request (not recommended)
        
        # Connection health check (Django 4.1+)
        'CONN_HEALTH_CHECKS': True,
        
        'OPTIONS': {
            'connect_timeout': 10,
            'application_name': 'my-django-app',
        },
    }
}
 
# For more sophisticated pooling, use django-db-geventpool
# or run behind PgBouncer

Ruby on Rails ActiveRecord:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# config/database.yml
production:
  adapter: postgresql
  host: db.example.com
  database: myapp
  username: appuser
  password: <%= ENV['DB_PASSWORD'] %>
  
  # Pool configuration
  pool: 10                    # Connections per worker process
  checkout_timeout: 5         # Seconds to wait for connection
  reaping_frequency: 10       # Seconds between connection cleanup
  
  # Connection settings
  connect_timeout: 10
  
  variables:
    statement_timeout: 30s
    
# Note: With Puma workers, total connections = pool × workers
# 4 Puma workers × 10 pool = 40 connections to database

Prisma (Node.js):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// Connection string in .env
// DATABASE_URL="postgresql://user:password@db.example.com:5432/myapp?connection_limit=20&pool_timeout=10"
 
// Connection parameters in URL:
// connection_limit — Maximum connections in pool
// pool_timeout — Seconds to wait for connection
 
// For serverless, use Prisma Accelerate or external pooler
// DATABASE_URL="prisma://accelerate.prisma-data.net/?api_key=..."
 
// Or configure with PgBouncer
// DATABASE_URL="postgresql://user:password@pgbouncer.internal:6432/myapp?pgbouncer=true"
 
// In code
 
 
const prisma = new PrismaClient({
  log: ['query', 'info', 'warn', 'error'],
  // Prisma manages pool internally
});
 
// Singleton pattern for connection reuse
let prismaInstance: PrismaClient | null = null;
 
export function getPrismaClient() {
  if (!prismaInstance) {
    prismaInstance = new PrismaClient();
  }
  return prismaInstance;
}
 
// Graceful shutdown
export async function disconnectPrisma() {
  if (prismaInstance) {
    await prismaInstance.$disconnect();
    prismaInstance = null;
  }
}

ORM Singleton Pattern

Most ORMs expect you to create a single instance that's reused across requests. Creating new ORM instances per request defeats connection pooling. Always use singletons or dependency injection to share the pool-enabled client.

Common Implementation Pitfalls

Even with good pool implementations, incorrect usage patterns cause problems. Here are the most common pitfalls across all languages:

Common Pooling Mistakes

•Creating pool per request — Pool should be created once at startup, not per request. Each pool creation opens new connections, defeating the purpose.
•Not returning connections — Failing to call release(), putconn(), or use context managers leaves connections checked out until timeout or garbage collection.
•Ignoring connection errors — Broken connections must be handled gracefully. Use validation/ping to detect and pool automatically replaces dead connections.
•Oversized pools — Setting max connections equal to expected concurrent users, rather than database optimal capacity.
•Ignoring slow queries — A few slow queries can monopolize all connections, starving fast queries. Monitor and optimize slow queries independently of pool size.
•Transaction leaks — Starting transactions without commit/rollback leaves connections in unusable state. Always use try/finally or context managers.
•Credential in connection string — Different credentials create different pools. Dynamic credentials cause pool multiplication.
•Missing connection timeout — Without timeouts, hung database causes requests to wait forever. Always configure connection acquisition timeout.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# WRONG: Transaction leak on error
def transfer_money_bad(from_id, to_id, amount):
    conn = pool.getconn()
    cursor = conn.cursor()
    cursor.execute("BEGIN")
    cursor.execute("UPDATE accounts SET balance = balance - %s WHERE id = %s", 
                   (amount, from_id))
    # If this raises an exception, transaction is never rolled back
    # Connection returned to pool in broken state
    cursor.execute("UPDATE accounts SET balance = balance + %s WHERE id = %s",
                   (amount, to_id))
    cursor.execute("COMMIT")
    pool.putconn(conn)
 
# CORRECT: Proper transaction handling
def transfer_money_good(from_id, to_id, amount):
    conn = pool.getconn()
    try:
        cursor = conn.cursor()
        cursor.execute("BEGIN")
        cursor.execute("UPDATE accounts SET balance = balance - %s WHERE id = %s",
                       (amount, from_id))
        cursor.execute("UPDATE accounts SET balance = balance + %s WHERE id = %s",
                       (amount, to_id))
        cursor.execute("COMMIT")
    except Exception:
        cursor.execute("ROLLBACK")
        raise
    finally:
        pool.putconn(conn)  # Always return, even on error

Defense in Depth

Configure pools to automatically reset connections on return (most do by default). This provides safety against transaction leaks—rolled back automatically. But don't rely on it; always handle transactions explicitly for correctness and clarity.

Summary: Implementation Checklist

Before moving to external poolers, ensure your application-level pooling is correctly configured:

Pool Implementation Checklist

•Pool created once at startup — Single pool instance shared across all requests.
•Appropriate pool size — Based on (cores × 2) + 1 formula, not arbitrary large number.
•Connection timeout configured — 5-15 seconds typical, fail fast preferred.
•Max lifetime configured — 15-30 minutes, shorter than infrastructure timeouts.
•Connection validation enabled — Use pool_pre_ping, testOnBorrow, or equivalent.
•All connections returned properly — Using context managers or try/finally everywhere.
•Transactions always finalized — Every BEGIN has matching COMMIT or ROLLBACK.
•Monitoring in place — Pool utilization, wait times, checkout times visible.
•Graceful shutdown — Pool closed properly on application termination.
•Aggregate capacity calculated — Sum of all instances stays within database limits.

Language-specific recommendations:

Language	Recommended Pool	Key Configuration
Java	HikariCP	maximumPoolSize, connectionTimeout
Python	SQLAlchemy QueuePool	pool_size, max_overflow, pool_pre_ping
Node.js	pg.Pool or mysql2.Pool	max, connectionTimeoutMillis
Go	database/sql built-in	SetMaxOpenConns, SetConnMaxLifetime
.NET	ADO.NET built-in	Max Pool Size, Connection Lifetime

What's next:

Application-level pooling handles single-process needs, but production systems with multiple instances need external poolers. The next page examines PgBouncer and ProxySQL—dedicated connection pooling proxies that aggregate connections across many application instances.

Page Complete

You now understand connection pool implementations across major programming ecosystems. The key insight: every modern language has good pooling options, but correct configuration and usage patterns are essential. Next, we'll explore external pooling proxies for multi-instance and serverless architectures.