These broken connections will also be detected by the testOnBorrow but it depends on the database driver, OS & network how fast this will be detected. If there are multiple broken connections in the pool this can take a relative long time but eventually all broken connection will be removed.
By the way, this won't help against a connection leak. If numActive reaches maxActive then all these connections are in use by your application and if it doesn't go down then somewhere, somehow the close method isn't called.
You could try to enable the abandoned feature or log the pool usage (numActive / numIdle) during the day and see how the pool usage evolves.
-- Dirk
Vjeran Marcinko wrote:
----- Original Message ----- From: "Dirk Verbeeck" <[EMAIL PROTECTED]>
To: "Jakarta Commons Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, August 18, 2004 11:42 AM
Subject: Re: [DBCP] Somebody explain me eviction feature ?
If you use testOnBorrow then you don't need testWhileIdle. Evicting old cnnections is usefull wel you have a database or firewell that closes idle connections.
But is 'testOnBorrow' sufficient even if I have this situation with firewall ? Or eviction feature should be enabled then beside 'testOnBorrow' ?
I am also wondering if I have this 'invalid' connection in pool, and validation querying should discover it, how long does it usually take for this validation query to fail (or throw exception) ? Is it momentarily, or this thread will wait for a while, thus applicaition user will think it has hanged ?
The reason for all this is because I have case where I use testOnBorrow feature (without idle evicting feature), in deployment with firewall between my app and db, my app always calls connection.close() in finally block, and my app gets stuck once every day. Number of connections in pool gets exhausted....
-Vjeran
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
