Re: DBCP status?

[Tim Funk]

That's all well and nice until a request fires a condition where it doesn't 
close the connection and takes down the server or makes all requests fail due 
to an exhausted pool. Which can only be fixed on the short term by a 
webserver restart. Which is what a sysadmin will due, report it in a log and 
the root cause doesn't get fixed.

I would be content to see it configurable to automagically close connections 
or just state a warning.

For me this isn't an issue since I wrote my own pool for my employer, but I'd 
rather dump my code and use one with more mindshare like dbcp. If I do that - 
automagically "killing" connections will be essential.

FWIW - in my pool code - I use a facade to mask the real dbms connection. If 
the too much time passes by - I close the real dbms connection(since the 
coder probably did lots of bad things) and set it to null so future attempts 
by the bad app immediately fails. In the context of a web request - this is 
acceptable for my situation. In hindsight - what I should do is throw a 
RuntimeException instead of having a NPE be thrown. The RuntimeException 
would have a "nice message" stating that the connection was closed because it 
was open too long. (I just thought of this 5 seconds ago, I haven't 
determined if its a good idea yet)

I'll try to stay quiet now (and go back to lurking since I'm not really 
contributing to commons, I apologize to all if I sound like noise) Hopefully 
closer to the 4th quarter - I can help out.

-Tim

David Graham wrote:

The pool should keep track of how long a connection has been checked out
and log a message when it passes some configurable threshold but it should
never try to grab the connection back from the application.
David


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]