Hi all, Phil, thanks for the explanations, very appreciated, I join Gary on saying that maybe my thoughts on Pool are based on incorrect assumptions. Assembling thought from various email and this thread IMHO starts being a little difficult, If we could resume all that thoughts in a wiki page I can take care on refactoring the code to see the design in action. WDYT? Have a nice day, Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, Nov 1, 2010 at 3:07 AM, Phil Steitz <phil.ste...@gmail.com> wrote: > On 10/31/10 9:47 PM, Mark Thomas wrote: >> >> On 31/10/2010 21:36, Phil Steitz wrote: >>> >>> A radical idea that I have been considering is to propose that we >>> dispense with keyed pools altogether. The DBCP need can be met without >>> them (see jdbc-pool) >> >> Can it? I know there are some things that DBCP can do that jdbc-pool >> can't such as https://issues.apache.org/bugzilla/show_bug.cgi?id=49543 >> >> I thought keyed pools were required for that but I haven't given it much >> more than about 10s thought so I could be wrong. > > For SharedPoolDataSource the way it is currently implemented, yes; but > similar to the statement cache, that class does not use anywhere near the > full features of GKOP. It does not allow you to provide a pre-configure GKOP > or support cross-pool maintenance. The only thing it really needs is > maxTotal enforcement and a map of GOPs. I guess having GKOP means you could > make SPDS more full-featured, but I wonder if its not overkill. > > Probably best to keep it around if we can find a simple performant way to > maintain it. > > Phil > > >> >> Mark >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
