Tomcat and Connection Pooling — How to Avoid Common Pitfalls

Creating a JDBC connection to a database is an expensive operation — on Oracle it takes 200–500 ms. A connection pool keeps pre-created connections and recycles them. Tomcat JDBC Pool vs. Commons DBCP — we strongly recommend the Tomcat pool.

Sizing¶

A pool that’s too small means requests wait. A pool that’s too large wastes resources on the DB server. For 200 concurrent users: 30–50 connections. maxActive must not exceed the PROCESSES limit in Oracle.

Connection Validation¶

testOnBorrow=true with validationQuery="SELECT 1 FROM DUAL" verifies every connection before use. testWhileIdle periodically checks idle connections. This will save you after a database restart or firewall timeout.

Abandoned Connections¶

A connection leak happens when a developer forgets to close a connection. removeAbandoned=true automatically detects forgotten connections. logAbandoned=true logs the stack trace of the allocation point.

Monitoring¶

JMX statistics: NumActive, NumIdle, WaitCount. If NumActive is consistently close to maxActive — there’s a problem.

Rules¶

1. Always use a pool, never DriverManager.getConnection() in production. 2. Use validation queries. 3. Enable removeAbandoned. 4. Set up JMX monitoring. 5. Test failover.