Daniel, On 8/5/25 12:43 PM, Daniel Schwartz wrote:
My understanding is that only as many connection objects are created and placed in the pool as are needed, so even if you set the upper limit high it doesn’t necessarily mean that you will have that many.
This is correct.
Once a database session terminates, then that connection object becomes available for future use.
Correct, as long as we agree on the definition of "database session". In the case of both JDBC and connection pools based upon JDBC connections, the definition of the "end of a session" is "calling Connection.close".
If you never call Connection.close, then every connection leaks, and most pools have features to help deal with those circumstances so that badly-written applications don't run out of resources.
So at any given time, the number of connection objects in the pool would be the maximum number of simultaneous connections that have been made so far, and not necessarily the total maximum that are allowed (in my case 1000). Is this correct?
More or less, though the pool may grown and shrink slightly around that value.
The pool Tomcat uses has features for logging and closing "abandoned connections" which are those which are checked-out of the pool but not properly-returned. I highly recommend enabling those features to investigate what is happening in your environment.
Otherwise, your 1000 connections will eventually be exhausted... it will just take much longer than the default 32 where you were observing that behavior.
-chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
