You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Holger Hoffstaette <ho...@wizards.de> on 2006/10/28 16:49:31 UTC
[pool] GenericKeyedObjectPool, WHEN_EXHAUSTED_BLOCK & multiple threads
I'm having a bit of a problem understanding a scenario for
GenericKeyedObjectPool. I need to WHEN_EXHAUSTED_BLOCK with a GKOP that is
used from multiple threads, but I cannot see how a blocking borrow(key)
can ever continue when another thread tries to returnObject(key, object),
as the methods are synchronized on the pool instance and would mutually
exclude each other?
Since I only need to block on a keys queue and not on the whole pool -
assuming I'm within the min/max limits - the only way around this seems to
be something like a ConcurrentKeyedObjectPool that does not synchronize
for the top-level map access but rather only on the second-level queue,
right? I was hoping to avoid that since it greatly complicates matters
regarding the pool's overall resource handling.
thanks,
Holger
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [pool] GenericKeyedObjectPool, WHEN_EXHAUSTED_BLOCK & multiple threads
Posted by James Carman <ja...@carmanconsulting.com>.
The java.util.concurrent package didn't arrive until JDK5, so I would doubt
that you can use that stuff in Commons Pool anyway. The Ant build says that
the source version is 1.4.
On 10/28/06, Holger Hoffstaette <ho...@wizards.de> wrote:
>
> On Sat, 28 Oct 2006 17:15:41 +0100, Marc Carter wrote:
>
> >> I cannot see how a blocking borrow(key)
> >> can ever continue when another thread tries to returnObject(key,
> object)
> > borrowObject() calls Object.wait() which allows other threads access to
> > the locked object (as opposed to Thread.sleep() which would not).
>
> You are completely right, I had completely forgotten that wait() gives up
> the monitor. Haven't used the manual wait/notify stuff for too long..
>
> > returnObject() calls notifyAll() which will (when returnObject() exits)
> > wake up the borrowing thread. Hence, WHEN_EXHAUSTED_BLOCK only blocks
> the
> > current thread from continuing execution, it does not stop others from
> > returning objects or using other key pools.
>
> Yay!
>
> > Although the wait/notify *could* be made more granular than the current
> > top-level implementation, this would only be a performance issue - the
> > current model will not block any other threads which can legitimately
> use
> > the GKOP.
>
> That was clear. I was thinking about adding a few performance-boosting
> things to GKOP (less granular locking via util.concurrent, Deques etc.)
> but for now I think I'll be a happy camper. It's not so much the glorified
> Map that I'm after but rather the factory-backed lifecycle model. If it
> were not for that I'd just have all threads grope around in a
> ConcurrentMap and be done. :D
>
> Thanks again for the heads up.
>
> cheers
> Holger
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
Re: [pool] GenericKeyedObjectPool, WHEN_EXHAUSTED_BLOCK & multiple threads
Posted by Sandy McArthur <sa...@apache.org>.
On 10/29/06, Holger Hoffstaette <ho...@wizards.de> wrote:
> On Sat, 28 Oct 2006 21:12:06 -0400, Sandy McArthur wrote:
> > The next release of pool has a KeyedObjectPool implementation that
> > basically uses a monitor per key. There is a "global" monitor for
> > accessing the the internal pool for the key but it is very briefly held.
> > This code has been in waiting for too long while I hoped to find time to
> > optimize it some more but that free time hasn't manifested itself. I'll
> > move to release Pool 2 with the current trunk in the next few days.
>
> Great! One other thing I found was that the second map for counting the
> per-key active objects can really be removed into having a simple
> QueueInfo object that holds the queue, int active objects and (maybe in
> the future?) other values. A simple "struct" with public fields should be
> enough for that.
Yea, that would probably be better than maintaining parallel maps. If
you want to create a patch and attach it to an issue I'll take a look
at including it.
--
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
Re: [pool] GenericKeyedObjectPool, WHEN_EXHAUSTED_BLOCK & multiple threads
Posted by Holger Hoffstaette <ho...@wizards.de>.
Hi Sandy,
On Sat, 28 Oct 2006 21:12:06 -0400, Sandy McArthur wrote:
> The next release of pool has a KeyedObjectPool implementation that
> basically uses a monitor per key. There is a "global" monitor for
> accessing the the internal pool for the key but it is very briefly held.
> This code has been in waiting for too long while I hoped to find time to
> optimize it some more but that free time hasn't manifested itself. I'll
> move to release Pool 2 with the current trunk in the next few days.
Great! One other thing I found was that the second map for counting the
per-key active objects can really be removed into having a simple
QueueInfo object that holds the queue, int active objects and (maybe in
the future?) other values. A simple "struct" with public fields should be
enough for that.
Holger
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [pool] GenericKeyedObjectPool, WHEN_EXHAUSTED_BLOCK & multiple threads
Posted by Sandy McArthur <sa...@apache.org>.
On 10/28/06, Holger Hoffstaette <ho...@wizards.de> wrote:
> On Sat, 28 Oct 2006 17:15:41 +0100, Marc Carter wrote:
> > Although the wait/notify *could* be made more granular than the current
> > top-level implementation, this would only be a performance issue - the
> > current model will not block any other threads which can legitimately use
> > the GKOP.
>
> That was clear. I was thinking about adding a few performance-boosting
> things to GKOP (less granular locking via util.concurrent, Deques etc.)
> but for now I think I'll be a happy camper. It's not so much the glorified
> Map that I'm after but rather the factory-backed lifecycle model. If it
> were not for that I'd just have all threads grope around in a
> ConcurrentMap and be done. :D
The next release of pool has a KeyedObjectPool implementation that
basically uses a monitor per key. There is a "global" monitor for
accessing the the internal pool for the key but it is very briefly
held. This code has been in waiting for too long while I hoped to find
time to optimize it some more but that free time hasn't manifested
itself. I'll move to release Pool 2 with the current trunk in the next
few days.
--
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
Re: [pool] GenericKeyedObjectPool, WHEN_EXHAUSTED_BLOCK & multiple threads
Posted by Holger Hoffstaette <ho...@wizards.de>.
On Sat, 28 Oct 2006 17:15:41 +0100, Marc Carter wrote:
>> I cannot see how a blocking borrow(key)
>> can ever continue when another thread tries to returnObject(key, object)
> borrowObject() calls Object.wait() which allows other threads access to
> the locked object (as opposed to Thread.sleep() which would not).
You are completely right, I had completely forgotten that wait() gives up
the monitor. Haven't used the manual wait/notify stuff for too long..
> returnObject() calls notifyAll() which will (when returnObject() exits)
> wake up the borrowing thread. Hence, WHEN_EXHAUSTED_BLOCK only blocks the
> current thread from continuing execution, it does not stop others from
> returning objects or using other key pools.
Yay!
> Although the wait/notify *could* be made more granular than the current
> top-level implementation, this would only be a performance issue - the
> current model will not block any other threads which can legitimately use
> the GKOP.
That was clear. I was thinking about adding a few performance-boosting
things to GKOP (less granular locking via util.concurrent, Deques etc.)
but for now I think I'll be a happy camper. It's not so much the glorified
Map that I'm after but rather the factory-backed lifecycle model. If it
were not for that I'd just have all threads grope around in a
ConcurrentMap and be done. :D
Thanks again for the heads up.
cheers
Holger
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [pool] GenericKeyedObjectPool, WHEN_EXHAUSTED_BLOCK & multiple threads
Posted by Marc Carter <MC...@uk.ibm.com>.
Holger,
> I cannot see how a blocking borrow(key)
can ever continue when another thread tries to returnObject(key, object)
borrowObject() calls Object.wait() which allows other threads access to
the locked object (as opposed to Thread.sleep() which would not).
returnObject() calls notifyAll() which will (when returnObject() exits)
wake up the borrowing thread. Hence, WHEN_EXHAUSTED_BLOCK only blocks the
current thread from continuing execution, it does not stop others from
returning objects or using other key pools.
Although the wait/notify *could* be made more granular than the current
top-level implementation, this would only be a performance issue - the
current model will not block any other threads which can legitimately use
the GKOP.
Marc
"Holger Hoffstaette" <ho...@wizards.de>
Sent by: news <ne...@sea.gmane.org>
28/10/2006 15:49
Please respond to
"Jakarta Commons Users List" <co...@jakarta.apache.org>
To
commons-user@jakarta.apache.org
cc
Subject
[pool] GenericKeyedObjectPool, WHEN_EXHAUSTED_BLOCK & multiple threads
I'm having a bit of a problem understanding a scenario for
GenericKeyedObjectPool. I need to WHEN_EXHAUSTED_BLOCK with a GKOP that is
used from multiple threads, but I cannot see how a blocking borrow(key)
can ever continue when another thread tries to returnObject(key, object),
as the methods are synchronized on the pool instance and would mutually
exclude each other?
Since I only need to block on a keys queue and not on the whole pool -
assuming I'm within the min/max limits - the only way around this seems to
be something like a ConcurrentKeyedObjectPool that does not synchronize
for the top-level map access but rather only on the second-level queue,
right? I was hoping to avoid that since it greatly complicates matters
regarding the pool's overall resource handling.
thanks,
Holger
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org