----- Original Message ----- From: "Danny Angus" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, July 22, 2003 3:18 PM Subject: RE: [DBCP] AbandonedTrace - Connection Recovery
> Juozas, > > > I think I will leave commons and I will spend more my time on SF > > with forked > > code, if this kind of vote can win at apache. > > My input is not a very big, but I will lose any energy to work for crap . > > I think it is sad that you would rather leave than suggest any alternative. > > It highlights my point though, why should we expect those in favour of its > retention to remain involved if we drop this when you won't remain involved > if it is not dropped? > > Surely we should at least _try_ to accomodate both points of view? Or are > also against even helping to find a compromise that would satify your > requirements? > > I can see no technical reason why this should not be done, perhaps you can? > If so why don't you help us by explaining why a compromise can never be > acceptable to you. I believe application must work with any kind of pool implementation and not to depend on wokarounds in pool. This kind of wokaround breaks contract and portability, but can not solve resource management problem. I do not think it is good idea to experiment on stable component and I think a new subproject is the best compromise in this case. Resource manager it is not a traditional pool of database connections. The idea is very simple: 1. "close" is a programming error in managed code. 2. Resource manager is backed by any pool implementation. It is very trivial to implement and to port/fix any "legacy code". > > d. > > > --------------------------------------------------------------------- > 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]
