Perhaps I was unclear what it is I'm trying to do. I have a connection pool set up under Tomcat 5.5, connecting to DB2 on an iSeries box using Tomcat's DBCP. It is set up for 30 connections. I am using Lambda Probe (a great open source Tomcat monitoring app) to monitor the datasources. It is showing, let's say, that there are a max of 30 connections allowed, that 11 have been "established", and 9 are "busy". I know that these 9 are due to a connection pool leak bug that was corrected (but not yet deployed), so even though the application has gone idle and no one is using it, the connections remain "busy" indefinitely. I have enabled removeAbandoned in my server.xml, but according to the Tomcat docs, abandoned connections are only recycled if there is a need for them, due to the number of available datasources getting low. The number of available datasources are not yet low, so these orphaned connections are still being reported as "busy". I'm a little bit anal with regard to keeping things kinda clean on the server, so I would like to have these abandoned connections no longer reported as "busy" once they are orphaned. Is there a way to find and recycle abandoned connections forcibly?
Thanks, David On 1/8/07, David Uctaa <[EMAIL PROTECTED]> wrote:
Tomcat provides the removeAbandoned and removeAbandonedTimeout parameters when setting up data sources in server.xml. But according to the documentation I've read, abandoned connections only get closed and recycled when available connections run low and new connections are requested. Is there a way for me to forcibly close/release abandoned connections on the server from a privileged application running on the same server? BTW, I'm running Tomcat 5.5 on a Windows 2003 box, running against DB2 on an iSeries box (jt400 for the JDBC driver), using Tomcat's DBCP for the pooling. Thanks, David
--------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
