--- "Ford, Mark" <[EMAIL PROTECTED]> wrote: > Entering in the middle here... > > I added a logging statement in my pool that reports overdue connections > and > it's been helpful in alerting us to problems. One thing to consider is > adding a hook that allows you to borrow a connection without generating > these errors if you know that you'll be using the connection for a long > time. For example, I have some background jobs that run and might use a > connection for upwards of 30 minutes or more. These shouldn't be grouped > in > with the same requests to my web app which should only need a connection > for > a few seconds at most. Perhaps too specialized of a requirement, but it > works for me ;)
This is exactly why DBCP should never grab connections back from an app. It doesn't have enough information to make that decision. > > Also, I went as far as wrapping the Connection object returned from the > DriverManager in my own so it could keep track of Statements that it > created > to ensure that they get closed. When the borrowed connection is returned > to > the pool it will log any open statements and the corresponding > stacktrace > for their creation and this has eliminated any statements being left > open. > This type of overhead is only necessary to weed out any mistakes early > on > and should be turned off for production code. This is fine for your app but shouldn't be added to DBCP directly. DBCP might provide hooks where you could plugin this behavior but resource cleanup is the app's responsibility. David > > - Mark > > -----Original Message----- > From: Anton Tagunov [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 01, 2003 10:40 AM > To: Jakarta Commons Developers List; [EMAIL PROTECTED] > Subject: Re[2]: DBCP status? > > > Hello David! > > DG> DBCP should not close connections that have been borrowed from the > pool. > > DG> It should only log a possible error when the configured time limit > has > DG> been exceeded. > > What do you think, should this overtimed connection still be > considered "active" for the purpose of enforsing > WHEN_EXHAUSTED_FAIL or > WHEN_EXHAUSTED_BLOCK? > > Should the active connection counter rather be decreased > by 1 once a connection overtimes? > > SK> c) support an optional debug step that will create a Throwable when > SK> getConnection is called. Then if the max-active threshold is hit, > we > SK> can print the stack trace of where the aged connection was grabbed, > and > SK> in development/testing, quickly resolve the errant connection. > > DG> I'm ok with this as long the stack trace isn't logged like an > exception. > > DG> It will be confusing for people to see a stack trace that isn't > really > DG> associated with an exception so the message should indicate that > it's > DG> identifying a possible connection leak location. > > We can envent some special exception, something like > > ConnectionOvertimeDetected > > or smth better, but give it such a descriptive name and message > that would save the user from confusion. > > Or we could create a cascading exception that would have > a getCause() method that would return the original exception > as the root cause (it is in some sense a root cause) > > - Anton > > > --------------------------------------------------------------------- > 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]
