> -----Original Message----- > From: Gary Gregory > Sent: Tuesday, October 12, 2010 17:08 > To: dev@commons.apache.org; 'joerg.schai...@gmx.de' > Subject: RE: [pool] runtime re-configuration > > > -----Original Message----- > > From: Jörg Schaible [mailto:joerg.schai...@gmx.de] > > Sent: Tuesday, October 12, 2010 16:42 > > To: dev@commons.apache.org > > Subject: Re: [pool] runtime re-configuration > > > > 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? > > It is easier to say: pool.setMaxActive(n); > > If changing these settings at runtime while enforcing proper semantics is a > big deal, we should create an immutable class with a mutable subclass.
Or provide mutable and immutable interfaces. Gary > > Gary > > > > > - Jörg > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org
