commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Agrawal, Vikram (London)" <>
Subject RE: [Pool] Some thoughts and proposals
Date Wed, 21 Aug 2002 17:06:25 GMT

It is not difficult to tweak the GenericObjectPool to provide this
functionality but I agree with you in that this implementation belongs to
the family of the StackObjectPool and therefore should get its base from
there rather than the GenericObjectPool.

I am planning to create a QueuedObjectPool and make it and the
StackObjectPool extend a common class firstly, to avoid duplication of code
and more importantly to emphasize that all the functionality in the
QueuedObjectPool and the StackObjectPool is exactly the same except for the
order in with the elements are returned.

Any inputs on this would be much appreciated.


-----Original Message-----
From: Waldhoff, Rodney []
Sent: 20 August 2002 12:50
To: ''Jakarta Commons Developers List' '
Subject: RE: [Pool] Some thoughts and proposals

> 1) I would like to see an implementation of the 
> ObjectPool which services requests in a 
> roundrobin fashion, i.e. the Object returned by 
> the pool is the one that was least recently 
> activated

Sounds great.  

It should be straightforward to create a QueueObjectPool derived from or
similar to StackObjectPool for this purpose.  It may take a bit more work to
have GenericObjectPool support this mode (or maybe it is sufficent to change
removeFirst calls to removeLast, I haven't dug around very deeply on this),
but it'd be a welcome feature there as well (IMO).  I look forward to the
patch (hopefully with unit tests).

> 2) GenericObjectPool currently throws 
> NoSuchElementExceptions which in
> my view looks misleading in the stack 
> trace as I have always associated
> them with Enumerations and the like.  

Despite what the JavaDoc says, NoSuchElementException is commonly used to
say "this collection is empty", both by Sun (for example,
LinkedList.getFirst, SortedMap.firstKey, Vector.lastElement) and by
commons-collections (for example, PriorityQueue.peek and SortedBag.first).

An ObjectPool is reasonably seen as a type of collection, and I'd argue that
NoSuchElementException is a reasonable thing to throw when the pool is empty
or exhausted.  The borrow method is saying "give me the next idle element",
and the exception really is saying there is "no such element".

> I would love to see customized exceptions
> being thrown here infact being declared by 
> the ObjectPool interface.

It might make sense to add a subclass of NoSuchElementException for this
purpose, though you'd want to either leave it generic enough to be used for
all "you can't borrow right now" causes, or enumerate causes for all
expected implementations.  I'm not sure I see enormous value here, but
others may disagree.

If you have received this e-mail in error or wish to read our e-mail 
disclaimer statement and monitoring policy, please refer to or contact the sender.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message