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
library!
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
option?
Pool 2.0 implements that "shutdown mode" behavior. I hope to remove
the "nasty checked exceptions" in Pool 3.0:
http://wiki.apache.org/jakarta-commons/PoolRoadMap 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.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
