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.
I strongly disagree. You getting paged due to someone's poor coding abilities is outside the scope of DBCP. There are much more effective ways of preventing pages than by developing a library that covers up coding mistakes so that they persist indefinitely.
So, what are these more effective ways to prevent pages?
The current dbcp code for detecting abandoned connections doesn't cover up the problem, it logs that there is a problem and correctly identifies the code responsible.
Yes, in a perfect world all code deployed would be thoroughly tested
and bug free. But I don't think that will happen in my lifeftime. The servlet containers db connection pool is the best place to detect
and correct this problem.
Whether the code to do this is in the DBCP core or in sub classes doesn't matter to me. Just as long as the ability to do this comes with the DBCP release.
Server availability is a very high priority for me.
DBCP should be designed in a way that allows behaviors to be plugged in which includes grabbing "abandoned" connections. This should absolutely not be shipped with DBCP because there is no reasonable way for it to know what is abandoned in every situation.
Great, we agree that the core of DBCP should be designed so that this feature could be implemented in a subclass. :-)
You may feel that there is no reasonable way to know when a connection is abandoned. Fine, you don't have to use it, work on the code, document it, support it, etc.
That is not a good reason IMHO to prevent those who feel it is a very important feature from including a sub class which supports this with the DBCP release.
Regards,
Glenn
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
