In addition to explicitly closing the connection, are you also explicitly closing out any prepared or callable statements?
I had overlooked this issue one time, and while it wasn't causing a great performance hindrance per se, I could tell by my monitoring tool that many rogue connections were still left open, and that can get ugly after a while, believe me. -----Original Message----- From: news [mailto:n...@ger.gmane.org] On Behalf Of Eric B. Sent: Tuesday, February 03, 2009 2:05 PM To: users@tomcat.apache.org Subject: Re: dbcp pool freezing > "Caldarale, Charles R" <chuck.caldar...@unisys.com> wrote in message > news:0aae5ab84b013e45a7b61cb66943c17215b604a...@usea-exch7.na.uis.unisys .com... > > From: news [mailto:n...@ger.gmane.org] On Behalf Of Eric B. > > Subject: Re: dbcp pool freezing > > > > Then the question becomes why aren't they being returned at all? My > > timeout is 20secs; I would expect, if the Abandon tracking was > > working properly for me, that the connections would be returned > > after 20secs to the pool, and another thread would be able to > > continue using it. > > If, as I suspect, you have a loop somewhere in your webapp that keeps > requesting connections, each recovered connection would be consumed as > soon as it's recovered. The webapp logic would use the connection > briefly, then try to go back and grab another one, and wait up to 20 > seconds for the next connection recovery. I'm happy to test out an validate that theory, but based on what I've seen so far, this isn't the case at all. I've been trying to figure out how to create an sql connection wrapper class to count the number of times the connection is opened and closed (as suggested by Philippe earlier in this thread), but am actually having trouble getting it to work. I can only assume I'm doing it incorrectly. In my current application, I know that one of my queries throws an SQL exception. If I comment out the code that generates this query (or fix the query properly), then this issue disappears. However, having now found this issue, I am more concerned about finding the root cause of the problem, as opposed to simply treating the symptom, as I am seeing the same issue manifest itself in another application that doesn't have the same SQL exception. And yes, my exception is wrapped in a try/catch/finally statement, whereby I have the connection.close() in the finally{} block. Any ideas how I can further track this down? Thanks, Eric --------------------------------------------------------------------- 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
