[snip]
On the implementation. I have not looked closely at the current
implementation as it is not used by the pool that I added to dbcp and I
was trying to start it as a simple implementation of the latest
specification. But it would seem an implementation of this should just
maintain a reference to Connection objects that it hands out and then
after the allowed time period, it should call Connection.close(). The
current jdbc specification states that a Connection object should not be
usable after Connection.close() is called and the jdbc2pool
implementation does not allow the Connection object to be used after
close is called. Note that implementation is not perfect in that it
needs to use wrapper implementations of Statement and ResultSet. But
the idea is that once Connection.close() is called it should be safe for
the pool to use the PooledConnection, which represents the physical
connection, to create another Connection object which it can hand out. It doesn't seem like an implementation that just calls
Connection.close() needs to be that coupled to the rest of the pool code
and a simple event/listener model is not likely to add a bug to the main
code.
The current implementation recover's the abandoned connection based on an inactivity timeout. So it has to track the last time the connection was used. This more tightly couples it to DBCP.
Regards,
Glenn
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
