On Tue, 2003-07-22 at 10:28, Juozas Baliuka wrote: > > I agree that this is an education/policy issue. But sometimes you need > > a stop gap solution to keep something running while the customer fixes > > the problem. > > > > I would like to see this stop gap solution included with the DBCP release. > > Along with quality docs on how to properly use a db connection pool and > > a big disclaimer that the recovery of abandoned connections should only > > be used as a stop gap in an emergency until the customer has time to > > fix their code. > > Try to implement yourself and I am sure the time to fix a problem will mean > forever > and crappers will blame you then server or app will crache. Do you want > to blame apache for this code ? This problem redirection will not help, but > if you want, you can maintain this crap yourself, > but do not try to redirect this problem to apache please. >
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. 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. 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]
