Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: domain of
 LBreisacher@seagullsoftware.com designates 12.6.96.2 as permitted sender)
From: Lee Breisacher <LBreisacher@seagullsoftware.com>
To: "commons-user@jakarta.apache.org" <commons-user@jakarta.apache.org>
Date: Thu, 3 May 2007 20:31:13 -0400
Subject: [pool] overly-aggressive locking on addObject()?
Thread-Topic: [pool] overly-aggressive locking on addObject()?
Thread-Index: AceN44U7gEU4eCQ4TfiN7EAI/5mL1Q==
Message-ID: <C8B84F0CE259774E8CA549BA7FFAE948021B2FD3BA@E2K7MB.seagull.nl>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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 k=
eep a minimum number of objects in the pool.

- My makeObject() method can sometimes take several seconds to make a poola=
ble object (yes, perhaps *that* is the cause of my problems, but there's no=
thing 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 addObj=
ect() 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 poo=
l.

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 Thr=
ead 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 "sync=
hronized" 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 t=
hat the call "out" to the client's makeObject() method in addObject() shoul=
d release the pool's lock. In fact, isn't it always a bit risky to hold ont=
o 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