Sandy,
Sorry I missed this, which is unfortunate since I have been banging my
head on DBCP-65 for several hours over the last week. See comments
inline below.
On 10/31/06, Sandy McArthur <[EMAIL PROTECTED]> wrote:
Phil and others interested in Pool and DBCP,
While working on resolving POOL-86 which is about finding a way to
trim the pool size down after a load spike to try to minimize used
resources during off peak load levels.
This is a reasonable requirement, IMO. Sometimes this happens after
dependent resource slowdowns as well as load spikes.
I've suggested a decorator that wraps a pool and monitors it's usage
and intercepts calls to returnObject and directs them to
invalidateObject occasionally in order to shrink the size of the idle
objects in the pool.
I think this is a good idea because it solves the deadlock issue
described in DBCP-65 when DBCP uses an evictor.
Can you explain exactly how this will solve DBCP-65?
The most crude form of the decorator would implement returnObject
something like:
returnObject(Object obj) {
if (Math.random() < 0.01) { // 1% of the time
wrappedPool.invalidateObject(obj);
} else {
wrappedPool.returnObject(obj);
}
}
more intelligent code could take in to account the actual number if
active and idle pooled objects. Hopefully that conveys the idea I'm
thinking of.
I like this idea, with the latter kind of implementation. It is
interesting to think about the performance implications of the crude
form under differing load profiles. It could hurt in some cases. Some
sort of rolling mean of idle connections or longest idle time would
probably be best to use (i.e., not just current data, but some measure
of how much headroom the pool has had recently).
This does have flaws in that it does require activity on the pool for
it to work because it wouldn't have it's own thread, but that is also
how it avoids the risk of deadlocks.
Is there any really threadsafe way to do it otherwise? Unfortunately,
the activity requirement is bad because the time when you want the
benefit is precisely when it will be slow coming.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
