commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: DBCP status?
Date Tue, 01 Jul 2003 20:22:02 GMT
David Graham wrote:
>>The approach I took was this....
>>a) support an optional max-active time threshold, which means there is a
>>
>>time limit to how long a connection can be marked as in use.
> 
> 
> There is a maxActive property of BasicDataSource that defines the maximum
> number of open connections.  Adding a time limit is reasonable if step b
> is changed below. 
> 
>>b) if this threshold is exceeded, you close the connection.  The value 
>>of trying to return it to the pool is minimal, while the downside of 
>>returning a mid-transaction/statement connection to a pool is very bad 
>>and nearly impossible to track down.
> 
> 
> DBCP should not close connections that have been borrowed from the pool. 
> It should only log a possible error when the configured time limit has
> been exceeded.

I *need* the pooler to close connections that have been borrowed from 
the pool and forgotten to be closed.  Can you give a) reasons why not to 
close them because of an optional parameter and b) suggested workaround?

> I'm ok with this as long the stack trace isn't logged like an exception. 
> It will be confusing for people to see a stack trace that isn't really
> associated with an exception so the message should indicate that it's
> identifying a possible connection leak location.

I think there's a relunctance (including mine) to create a dependency on 
commons-logging (or another logger), so I was thinking about a 
PoolListener service.  There would be classes of events for:
a) creating a connection
b) grabbing a connection
c) closing a connection
d) a connection getting too old

...whatever else.  I haven't thought through all the types of events, 
but I think allowing an optional listener(s) to attach to the pool would 
be even better than spewing log messages out.  We'd want to provide at 
leats one debugging pool-listener that prints debug messages.

-- 
Serge Knystautas
President
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message