commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lee Breisacher <>
Subject [pool] overly-aggressive locking on addObject()?
Date Fri, 04 May 2007 00:31:13 GMT
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?



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

View raw message