commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <sandy...@gmail.com>
Subject Re: [pool] overly-aggressive locking on addObject()?
Date Fri, 04 May 2007 14:50:40 GMT
Lee,

The additional synchronization was needed for correct thread-safety.
Unfortunately it does make the pool a bit of a bottleneck as your
example demonstrates.

If you feel you don't need all of that synchronization and the pool
will be correct enough without it then I suggest you take the source
to a pool implementation you like, copy it to a private package and
modify it.

Someday I hope a much more concurrent pool is written but that is hard
thing to get right. Until then that is the best I have for you.

On 5/3/07, Lee Breisacher <LBreisacher@seagullsoftware.com> wrote:
> I'm running into a performance problem and I think it can be attributed to some overly
aggressive locking in GenericObjectPool>addObject(). Or perhaps I'm not using the APIs
just right, and someone can point out a better path for me.
>
> Here's the scenario:
>
> - I have a GenericObjectPool with a minIdle setting so it always tries to keep a minimum
number of objects in the pool.
>
> - My makeObject() method can sometimes take several seconds to make a poolable object
(yes, perhaps *that* is the cause of my problems, but there's nothing I can do about it).
>
> - Sequence of events:
> 1. Thread A borrows an object that causes the pool to be completely empty.
>
> 2. The ensureMinIdle() method (called from the Evictor thread) calls addObject() which
locks the pool and calls my (long-running) makeObject().
>
> 3. Thread B wants to borrow an object, but notices the pool is empty so it waits (that's
logic in my code).
>
> 4. Thread A finishes with its borrowed object and calls returnObject(), but returnObject
cannot enter because the pool is locked from step 2 (which is still running in makeObject()).
So thread A is stuck waiting on the pool's lock.
>
> 5. Finally, makeObject() finishes and adds the newly made object to the pool.
>
> 6. Thread A's returnObject now gets the lock and returns the object to the pool.
>
> The performance problem is at step 4 -- there's an object available for Thread B to use,
but it cannot get a hold of it.
>
> Note that this was not a problem with commons-pool 1.2 - several more "synchronized"
were added to methods in version 1.3. Perhaps those "synchronized" are necessary to prevent
other kinds of deadlock or race conditions, but perhaps the locks are a bit too aggressive?
In particular, it seems to me that the call "out" to the client's makeObject() method in addObject()
should release the pool's lock. In fact, isn't it always a bit risky to hold onto a lock during
a call out to a client method?
>
> Has anyone else run into this problem? Am I way off base in my addObject() suggestion?
>
> Thanks,
>
> Lee
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>


-- 
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message