Making pool be able to be resized at runtime will introduce extra complexity, that could be otherwise totally delegated to a BlockingQueue as backend structure.
Moreover is there some ideas of what kind of implementation will be used to implement the pool v2 ? ArrayBlockingQueue is IMO a good candidate, and it even has a "fair" behavior that jdbc-pool try to reimplement on its own. Kind regards, Benoit. 2010/10/13 Simone Tripodi <simone.trip...@gmail.com> > Hi guys, > I'd add that not all properties are configurable, we should add > setters only in case it makes sense, or not? > All the best, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Wed, Oct 13, 2010 at 2:19 AM, Phil Steitz <phil.ste...@gmail.com> > wrote: > > > > > > > > > > On Oct 12, 2010, at 4:42 PM, Jörg Schaible <joerg.schai...@gmx.de> > wrote: > > > >> Gary Gregory wrote: > >> > >>> I too would like to be able to tweak the size of the pool at runtime. > >>> > >>> Gary > >>> > >>> On Oct 12, 2010, at 13:19, "James Carman" <ja...@carmanconsulting.com> > >>> wrote: > >>> > >>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi > >>>> <simone.trip...@gmail.com> wrote: > >>>>> Hi Phil! :) > >>>>> honestly I didn't understand which are the use cases when a pool > needs > >>>>> to be reconfigured, that's why I've always used the pool in > "configure > >>>>> and use" modality and Seb's suggestion sounded good to me. OTOH I > >>>>> didn't modify any single code line before hearing your thoughts since > >>>>> you know much more than me. > >>>>> If pool's property are mutable, so I need to add the setters, make > >>>>> them final otherwise :P > >>>> > >>>> What if you want to alter the way the pool works at runtime? Perhaps > >>>> you're seeing that it keeps causing long waits because you're not > >>>> allowing it to grow big enough? > >> > >> Why then not create a new pool and take over ownership of the objects? > >> > > There may be instances out in circulation. Also requests waiting, > maintenance in progress, etc not to mention the need to redirect clients. > The flexibility to be able to increase pool size or change other parameters > on the fly is good IMO and where we can safely support it without > performance impact we should. > >> - Jörg > >> > >> > >> --------------------------------------------------------------------- > >> 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 > >
