> > This attitude is not very helpful. I don't see how dbcp supplying the > ability to configure a connection pool to reclaim connections is that > big of an issue.
Have you tried to solve problems this way ? Is it tested solution and can be used for "high quality software" ? Try to implement and test anti patterns at home first. It adds code complexity, but if the implementation is > modified so that it is not central to the rest of the code and the > critical bug entered against the current implementation is solved, we > should allow it as part of the release. > > I was for the removal of this code, assuming the contributor had > abandoned it and it had bugs no one else wanted to fix. But it is a > perfectly valid feature and the original developer is stating he is > willing to rewrite it. > > Is it not possible for many databases to configure an idle timeout? I'm > pretty sure this kind of ability is to handle the same sort of badly > written client code. Does mysql get blamed if a poorly written > application loses a connection because it leaked it and did not close > it, but mysql reclaims it. It is not a feature too, It breaks transactions, I do not believe it supports "autoreconnect" if transactions are enabled. How about if the db admin sets the timeout > too low and some normal running process ends up corrupting the data > because it held a connection too long. I don't think so; it is > important that the configuration options are set appropriately for the > apps that will be using the database/connection pool. We are not taking > on any responsibility for someone's crappy code by such a feature. > > Consider that you are using dbcp as your connection pool and your code > is error-free. You are awaiting a feature from a > partner/subcontractor. The feature runs some reporting queries on an > interval of 15 minutes and it is known that the queries generally take > about a minute. It turns out the partners code is flawed and you are > going to lose money, if you have to wait for a fix and start integration > testing again after a delay. There might be all sorts of other remedies > to this, but being able to configure the pool to recover the connections > in the pool being used by the partners code would be optimal, imo. You > can then just continue, or worse case immediately start over on, your > integration testing. > > Features related to connection management are appropriate in a > connection pool. Is it inappropriate for tomcat to allow an admin to > configure a security policy, since well written code will not do > anything it shouldn't? > > 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. > > Why is this such a contentious issue? > > john mcnally > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
