> "Caldarale, Charles R" <[email protected]> wrote in message
> news:0aae5ab84b013e45a7b61cb66943c17215b604a...@usea-exch7.na.uis.unisys.com...
> > From: news [mailto:[email protected]] 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: [email protected]
For additional commands, e-mail: [email protected]
