commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom <>
Subject Re: pool: stack, cycle and eviction
Date Wed, 31 May 2006 05:43:44 GMT

> I think a LIFO pool plus an evictor will fix the wasted resources
> problem under low load following a high load.

I would use normal and high load, since the scenario can scale to any 
number, but agreed. Thank you for confirming the scenario!

>> Since the sequence of objects in the stack is random,
> Umm, that statement is incorrect. The idle objects in a stack based
> pool would have the stalest objects on the bottom. It may be random
> with respect to the order the object were created but the order with
> respect to when they were returned is very specific.
Correct, I did mean random in light of the usage of the object; it is 
not like one object is borrowed preferred over another because of, say, 
better performance. The pool has no feedback logic where objects 
associated with lesser burdened resources have a higher borrow priority 
- if you get what I mean - of course there is an ordering according to 
"staleness" possible. Hmmmm, it would be an interesting add-on to the 
pool though, callbacks so the objects can be prioritized.

>> If the evictor uses the same access as a regular client,
> It doesn't use the same access as a regular client. Otherwise the
> evictor would be an external process to the pool and wouldn't have
> special access to the stalest objects first.
 From a locking perspective., the evictor of course needs access to 
internal information to determine staleness.

>> I do not see why it would deadlock. (I understand your
>> locking explanation.) Again at the risk of insulting people: if the pool
>> eviction thread uses a two stage approach:
>> 1) decide how many objects need to be evicted
>> 2) using the regular client call and borrow the determined number of
>> objects from the pool, but then use an inside call to destroy the object
> Are you saying the evictor should call borrowObject() and then call
> invalidateObject() for however many objects need to be evicted?
Basically: yes. But that would be my approach: whenever multithreading 
locking is an issue, I try to stick to a single locking path. Maybe not 
optimal compared to an internal approach, but apparently we are in a 
"low", because we are cleaning up. And the actual clean up (closing) of 
the resources is probably way heavier than any overhead in the queue due 
to the straight forward solution.

> Now, this deadlock issue goes away if the Pool never calls out to the
> PoolableObjectFactory methods while it is holding it's internal
> "PoolLock".
I totally believe you :-) What the hell am I talking about? I don't know 
the source code at all. And I forgot to thank the developers for a great 

> Not really, just when it's done. My spare time for pool has decreased
> with the approach of my wedding. But you can always get the code from
> subversion trunk or a nightly build but do realize they are
> unsupported and the API of new code may not be stable yet. Feed back
> is welcomes though.
Oh, congratulations then! I don't know if you have or can or want, but 
you should experience the decrease in spare time due to childeren! Hehe.

> Personally, I think the composite pool code in the trunk is quite
> robust and solid. The current problem is it is not really any faster
> than the existing pool implementations.

Hm. Good to hear, I'll take a peak. Is performance an issue?

> I may punt this until Pool 3.0 where we require Java 5 and
> the java.util.concurrent classes are available.
Hm. Personally I love Java 5, but I can't seem to get all my clients to 
move. Forcing the pool library to 1.5 will probaby mean a lot of 
projects cannot follow. Would using the original locking library (or 
-dare I say-  embedding one or a few classes from that library) be an 

> Pool 2.0 implements that "shutdown mode" behavior. I hope to remove
> the "nasty checked exceptions" in Pool 3.0:
> Since removing
> checked exceptions from an interface breaks API compatibility with
> existing implementations I'm not eager to push that change into Pool
> 2.0.

Using the wrapper approach you can offer both without much additional 
effort. Basically all you need is two additional classes to maintain: 
one interface (copy of the actual pool) without the checked exceptions 
and one implementation doing a call-and-wrap-in-unchecked-exception for 
each method. It's livable.


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

View raw message