On 12/8/21 1:44 PM, Christopher Schultz wrote:
Phil,
On 12/8/21 15:23, Phil Steitz wrote:
On 12/8/21 6:36 AM, Christopher Schultz wrote:
Jerry,
On 12/7/21 20:59, Jerry Malcolm wrote:
Chris, The way I thought it worked was if I configured
'RemoveAbandonedOnBorrow' and RemoveAbandonedTimeout="15" was that
each time I requested a new connection from the pool, any
connections that had been idle for >15 minutes and had not been
returned by my code to the pool would be recovered, returned to the
pool and logged (assuming logAbandoned was set).
Nope. "removeAbandoned" causes any connection that isn't returned to
the pool to be *removed from the pool*, and replaced with a new
(presumably working) connection. The connection that was never
returned ... stays out there, doing whatever it was doing.
Not exactly. Abandoned connection cleanup does try to physically
close connections [1] that are deemed abandoned. It creates capacity
to create new ones but it does not create them immediately.
"logAbandoned" just lets you know when the pool gives up. It doesn't
"do" anything (other than the logging).
The alternative would be for the pool to forcibly terminate the
connection, which could cause all kinds of chaos, so it does the
only thing it can reasonably do: forget the connection ever existed
in the first place. If your code never closes it, and the Connection
object never gets GC'd (and, presumably, closed in the process),
then it just lived forever, wasting an open-connection to your db.
Since you have limited your total connections (per user? per host?)
you eventually run out due to the leak.
This is why you need to be careful to set the abandoned timeout long
enough so that "chaos" does not ensue. The pool tries to physically
close abandoned connections when this is configured to happen. If
clients retain handles to them and later try to use them, they will
get exceptions. You can see this confirmed in DBCP's
TestAbandonedBasicDataSource unit tests.
Oh, I had no idea DBCP was actually trying to kill those connections.
I guess reasonable can disagree over whether or not those connections
should be killed by DBCP.
Yeah it has been that way since inception. The problem with not
actually closing them is you end up creating problems on the DB side if
you leave them hanging. Also kind of defeats the purpose of the pool
and changes its contract vis a vis the factory (maxTotal means a pool
will not take up more than that many instances at a given time).
Phil
I'm cool either way :)
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
