Actually, commons pool already depends upon commons collections, so it's not that much of a stretch.
-----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 09, 2005 8:57 AM To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Subject: RE: Pool: comments requested for a new implementation If you don't mind a dependence upon Commons Collections, you should come up with a BufferPool, using the Commons Collections Buffer interface. The Buffer interface allows you to abstract away the LIFO vs. FIFO vs. priority queue vs. some other implementation stuff. All you do is call remove() and add(). That way, if you wanted a new type of pool, you just supply a different implementation of Buffer. Just an idea! :-) -----Original Message----- From: Sandy McArthur [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 09, 2005 1:17 AM To: Jakarta Commons Developers List Subject: Pool: comments requested for a new implementation In the past weeks I've been working on a new implementation for Pool that I'm calling a Composite Object Pool (COP). I'm at the point where I think I've implemented everything I think the pool should have and then some. I would like feedback on the code and if the response is favorable I'll submit it for addition to the pool project. Generated JavaDocs and source code can be found at: http://sandy.mcarthur.org/pool/ Below is a list of things going for this code: * Implements almost all existing features in the current implementations. I think the ability to specific a minIdle object count and to skip validation when borrowing objects are the only existing features not implemented. I think it's wrong to not implement the former and I'm not convinced the ladder is really a good thing. * Very consistent features/behavior across pool types. The feature set of GenericObjectPool (COP) is quite different than StackObjectPool (SOP). With COP the features available to a LIFO (SOP) are the same as the features available to a FIFO (GOP) * Only returns an activated and valid object or a newly created object. It seems silly to me to require clients of an ObjectPool to deal with checking and validating borrowed objects. * Pools are named by what they do, not how they are implemented. eg: LifoOP vs StackOP * Active objects that are not returned to the pool can be detected. Optionally, the stack at time of borrow for lost objects can be logged to aid in debugging. I think this feature is pretty cool. * Synchronization is maintained via a private lock idiom. * Keyed pools have fine grained locking when possible. * Very modular code. A pool's feature set is assembled with composition. * All CompositeObjectPools share the same java util Timer thread. * Idle object evictor turns itself off when the pool is empty to reduce useless work. * Idle object evictor will try to limit how long it keeps the pool tied up during evictions. This is similar to GOP.setNumTestsPerEvictionRun(int) but time based instead of object count based. * The pool factory minimally tries to optimize the the composed object pool based on parameter values. * Future proof. (soon to be famous last words?) None of the implementation is made visible and could be gutted and replaced without breaking 3rd party code. * Keyed pools can use a non-keyed PoolableObjectFactory too. * No decencies beyond the Java 1.4 JDK. It wouldn't be hard to make it Java 1.3 compatable. Things left to do are: * Fix any JavaDoc mistakes. * Implement more unit tests and fix any bugs that turn up. (denotations welcome.) * Current idle object evictor code behaves in a way similar to the GOP's evictor code. For this to be thread-safe all other access to the pool while evicting idle objects must be blocked and it is not very deterministic for when an idle object will actually be evicted. * Create/Run some benchmarks to verify the performance is good. * When Java 1.5 is considered a reasonable requirement the util.concurrent can probably be used to improve parallelization. -- Sandy McArthur --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
