On Mon, 2006-02-20 at 22:56 -0500, Sandy McArthur wrote: > I'm planning a helper class for Pool similar to the > java.util.Collections class. Below are the static methods I'm thinking > of implementing. Let me know if I forgot anything, misnamed anything, > added too much. > > * Two synchronizedPoolableFactory(factory) methods that take a > [Keyed]PoolableObjectFactory and wrap them in a synchronization > wrapper.
+1 > * A few prefill(pool, count) methods that call addObject() the > specified number of times. +1 > * Some checkMinIdle(pool, minIdle, period) methods that use a > java.util.Timer and periodically check the pool and call addObject as > needed to keep a minimum idle object count. +1 > Personally I don't like Pools that try to keep pre-made idle objects > in the pool. Best case it increases start up time, worst case consumes > cpu and memory that never gets used. Still, some people people think > they need this feature and this gives them a very similar feature > without complicating the pool implementation. personally speaking, i can see it both ways. but this sounds like a good plan... > * A series of adapt(...) methods that allow the user of a > KeyedObjectPool or KeyedPoolObjectFactory where a non-keyed > implementation is expected or vice-versa. The key would be specified > at the time the adapt method is called and could not be changed. > > I'm a little iffy in this feature. In included it because the > composite pool implementation does something similar to allow a > KeyedObjectPool be literally implemented as a map of ObjectPools. From > the point of view of the programmer using pool I'm not so sure this > feature is needed enough to justify itself as part of the client api. probably ok for a booch utility - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
