2010/10/17 Phil Steitz <phil.ste...@gmail.com> > On 10/17/10 8:53 AM, Benoit Perroud wrote: > >> 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. >> > > I don't understand exactly what you are saying here. The question is > should the user-exposed properties governing the size, max number of idle > elements, etc. be mutable at runtime. Regardless of the choice of data > structure to maintain the pool, deciding this in the negative puts some > serious constraints on user code. > > I mean, if we decide to use a BlockingQueue as backend and allow users to resize the queue, then we will need to reinstanciate the queue at every size change.
In jdbc-pool at least, in case of unfair queue, they use a ArrayBlockingQueue, and thus the queue size is not resizable on the fly. > We should talk about why the Tomcat devs decided to implement their own > FairBlockingQueue. Good point for the fair queue. Is something from Tomcat reading this ML ? As a side note, as of 1.5, the now "legacy" [pool] code implements fairness. > The Tomcat code is configurable - i.e., can behave fairly or not. I have > just started analyzing the performance tests included in jdbc-pool, but they > appear to indicate that, as expected, fairness dampens mean response but > decreases variance. I like the approach of making fairness configurable. >
