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]
