It appears clear that there are two camps, each with fairly strong views. Personally, I believe that both camps can be accomodated in a way that should satisfy both.
DBCP should focus on core pooling behavior related to connections and prepared statements, and leave policy issues to specialized subclasses. If DBCP is clean, without any reclaiming of connections and properly setup to be subclassed, including subclassing a delegating connection, then whomever needs a specialized connection pool that reclaims connections based upon some policy can do so.
DelegatingConnection, and the rest of the core objects should be pure and focused only on the necessary behavior to implement connection pooling. DBCP should focus on what has to happen when a connection is requested or returned. Behavior, not policy, should be the watch word. There is enough behavior to deal with related to connection pooling, including ensuring the proper state of pooled connections.
Some of the "AbandonedTrace" behavior is still necessary to implement the JDBC specification. Connections still need to track outstanding statements and results sets, which are closed by Connection.close(). However, the "abandoned" semantic is not in the specification. It is perfectly permissible to leave a ResultSet or Statement open, and expect the connection to close it. Nor is it necessary for DBCP to track leaks, regardless of whether or not it is implementing recovery. Both of that behavior can be implemented by specialized subclasses. DBCP may wish to provide abstract classes that facilitate specialization.
I fess up, I am the guilty party who added the ability to trace abandoned connections and recover them. ;-)
Sorry to jump in late on this. I have been busy with other things.
The motivation behind this was to allow a servlet container to continue operating normally even if you have customers who either wrote crappy code themselves or hired consultants who wrote crappy code. This helps improve servlet container availability in these situations and logs information which can help track down the problem. The only solution when crappy code causes problems with exhausting the connection pool is to stop and restart the container. I don't know about you, but I don't like getting paged in the evening or on weekends due to someone elses crappy code.
I can appreciate the arguments for a cleaner DBCP implementation. And refactoring its design to clean it up can be a good thing.
But the ability to track and close abandoned db connections is vital from my perspective. I strongly urge that the ability to do this be retained in DBCP. If the refactored core of DBCP allows this by subclasssing it, great. But those sub classes to support this should be released with DBCP.
Regards,
Glenn
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
