commons-dev mailing list archives

Serge,
> 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?
Why? I can think of a couple of reasons you might give, but I'm seriously not convinced that
it is a legitimate thing for the pool to do.
Can you sell it to us?
> 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.
FWIW I authored a JDBC connection pool and file & URL cache library for work, my experience
is this.. we started off with logging, it is vital to know exactly what the pools and caches
think is going on while your library is under development.
However once we started putting stable product into other software we quickly discovered that
logging is unnecessary, if anything is going on you use a debugger, if it is going well you
don't want the kind of logs these things produce. We eventually added a listener API and found
it to be much more satisfactory.
+1 to that idea.
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
I think that if in case d) your listener can intervene in the connection lifecycle then it
is unnecessary to have DBCP frceably close connections.
d.