It is nothing bad to add some logging to pool, but no workarounds. Application must work with any pool implementation and not to depend on workarounds in pool. But I see nothing bad if application uses resource manager (It is not a pool) and *never* closes connections, connection returned from this kind of manager must throw Exception on "close". It is very bad thing to break contracts in stable componnents, just for some crapy application support. Read arhives, it was discussed a lot of times in [dbcp].
----- Original Message ----- From: "Ford, Mark" <[EMAIL PROTECTED]> To: "'Jakarta Commons Developers List'" <[EMAIL PROTECTED]> Sent: Tuesday, July 01, 2003 5:07 PM Subject: RE: Re[2]: DBCP status? > 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 ;) > > 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. > > - 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] > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.491 / Virus Database: 290 - Release Date: 2003.06.23 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
