--- Tim Funk <[EMAIL PROTECTED]> wrote: > 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.
If one of your apps can take down your whole server, nothing we could do in DBCP will help you. Not closing connections is one of many bugs that can occur in an application and the prevention of those bugs is not DBCP's responsibility. The detection and notification of lost connections should be DBCP's responsibility to speed debugging. David > > 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] > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
