--- Phil Steitz <[EMAIL PROTECTED]> wrote: > David Graham wrote: > > --- "Noel J. Bergman" <[EMAIL PROTECTED]> wrote: > > > >>David, > >> > >>I hope that you have not gotten the impression that I am arguing with > >>you. > > > > > > Nope, I was just stating my point of view :-). I will continue to > argue > > against recovering connections until someone can make a solid case > that > > persuades me otherwise. > > Here is an attempt at making the case for some form or "connection > recycling" or "aggressive connection management". I have tried to > address your main points, which I agree are the central ones. Please > take this for what it is -- just another viewpoint based on what may be > incomplete or incorrect understanding of what dbcp is trying to do. > > > Here are the main problems: > > > > 1. Pools should not grab resources back from applications. > > Unless there is a contract that says that connections not used for more > than a configurable "Orphan timeout" can be reclaimed. Are you ruling > out this possibility? See for example, the configuration parameter > called "Orphan tiemout" defined here: > http://publib7b.boulder.ibm.com/wasinfo1/en/info/aes/ae/udat_was4poolset.html. > > Client apps are free to set the timeout to be effectively infinite if > they want and connections enlisted in transactions are not reclaimed. > Note that even if the pool doesn't do it, the engine eventually will > timeout unused connections anyway.
Of course if you define the pool contract that way then it is allowable. The separation of concerns I'm defining says that DBCP is responsible for maintaining a connection pool and clients are responsible for borrowing and returning connections. Putting connection reclamation into DBCP is an undue burden on it when the logical place for that responsibility is with the client. > > > 2. Even if pools were allowed to do that, there is no algorithm for > doing > > so in a reasonable manner. > > I agree that there is certainly no algorithm for divining when a > connection has been abandoned by an application. If the pool has > knowledge of when connections are being used, however, it can certainly > enforce idle timeouts. If there is no sound algorithm, how can DBCP enforce idle timeouts? The most DBCP should do is log a possible connection leak because it lacks enough information to make a judgement about leaked connections. Only the client application has that information. This is also a reason why DBCP should not ship with a pluggable "connection reclamation" behavior. > > > 3. There seem to be no reasons other than laziness or fear for > wanting > > the pool to reclaim connections. > > Fear is a good thing for resource managers (or any other server > component). > > What it comes down to here, IMHO, is what dbcp wants to be. If it wants > > to be a lightweight component used by single applications in a > controlled environment, then it does not have to be robust against > misbehaving clients, clients that abandon connections, or clients that > hold idle connections too long. If the aim is something like Tomcat + > dbcp = <insert your favorite commercial container> - EJBs, then it needs > > to be more robust. DBCP can be robust without reclaming connections. > > > > > I am open to designing DBCP in such a way that allows people to plugin > the > > behaviors they need including reclaming connections (the Strategy > pattern > > may be useful here). However, DBCP should never provide that > > functionality out of the box because it implies that Jakarta supports > poor > > programming practices. > > I disagree with the assertion that making the pool robust against > abandoned connections supports "poor programming practices". First, > just because an API can be misused, that does not mean that the design > of the API promotes or encourages the misuse. Second, in a shared > environment, there may be situations in which connections get > effectively abandoned without "poor programming practices" -- at least > not in the database access code. The EAI or network infrastructure, for > example, behind one of the apps could cause it to grind to a halt, > effectively orphaning any connections that it has open, depriving the > other apps of these resources. Here again, it depends on what the goal > of dbcp is. If deployment in large scale apps in a shared environment > is a goal, then it needs to aggressively manage resources. I disagree. If your environment has the above characteristics, each application would have its own separate connection pool so a failure in one app would not affect another. David > > Obviously, all of this is just my own point of view and since I have > contributed nothing to dbcp, it should not carry much weight. If others > > feel the same way, however, and there is interest in either developing a > > pluggable strategy to support configurable "connection recycling" or > other connection management extensions, I would be willing to help out. > > Phil > > > > > I believe debate is a great way of coming to a solution. Thanks for > > participating in this one. > > > > David > > > > > >>I asked you what you felt had led to the previous problems. There are > >>clearly differences of opinions amongst the people asking for and > >>rejecting > >>the idea of recovering connections, and I wanted to hear what people > >>thought. > >> > >> --- Noel > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > > > __________________________________ > > Do you Yahoo!? > > SBC Yahoo! DSL - Now only $29.95 per month! > > http://sbc.yahoo.com > > > > --------------------------------------------------------------------- > > 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] > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
