commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ford, Mark" <>
Subject RE: Re[2]: DBCP status?
Date Tue, 01 Jul 2003 15:07:42 GMT
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 []
Sent: Tuesday, July 01, 2003 10:40 AM
To: Jakarta Commons Developers List;
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
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


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:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message