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]
