Tomcat JDBC pool reaches maxActive while abandoned connections await removal

Goal

Choose removeAbandonedTimeout for the org.apache.tomcat.jdbc.pool.DataSourceFactory pool so leaked checkouts are reclaimed without interrupting legitimate long-running transactions.

Constraints

removeAbandoned must be true for removal, and abandonWhenPercentageFull plus removeAbandonedTimeout decide when a checked-out connection is abandoned. A timeout shorter than the longest transaction can interrupt active work; a timeout too long lets leaked connections accumulate until maxActive rejects new requests. Defaults and attribute availability vary by Tomcat version. Confirm the factory class and attribute names for the version in use. logAbandoned stack traces identify the leaking code path but add checkout overhead under concurrency. Resource settings in context.xml or server.xml are not interchangeable with Commons DBCP or HikariCP properties.

What is the safest way to bound removeAbandonedTimeout against observed transaction durations without prior production incident data?

Should abandonWhenPercentageFull be tuned before enabling removeAbandoned, or does removal depend primarily on the timeout?

How does enabling logAbandoned change the leak-detection trade-off in a high-concurrency web application?