Re: [Fwd: Pool contracts (Was Re: [Fwd: [C2] [Bug] ComponentNotAccessibleException])]

[Peter Donald <do...@apache.org>]

At 09:35  26/2/01 -0500, Berin Loritsch wrote:
>I have a feeling that we are dealing with a Race Condition on the
AbstractPool.

quite Possible.

>I think we should make all Pools ThreadSafe.  This contract will make things
>alot easier for people who are implementing pools in concurrent execution
>environments (i.e. multithreaded).  In cocoon, I will explicitly synchronize
>the get() and set() methods--but this is a temporary stop-gap until we make
>the Pool implementation thread-safe.

All pools used in a multithreaded environment should use ThreadSafePool.
DefaultPool is for use in single-threaded environments.

>I do think there is room for multiple different types of pools:
>
>* Hard resource limiting (Absolutely no more than X components)
>* Soft resource limiting (May have more than X, but extras are destroyed
when returned)
>* No resource limiting (As extras are needed, they are created and
maintained)

agreed ;)
Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: [Fwd: Pool contracts (Was Re: [Fwd: [C2] [Bug] ComponentNotAccessibleException])]

[Berin Loritsch <bl...@apache.org>]

Peter Donald wrote:
> 
> At 09:35  26/2/01 -0500, Berin Loritsch wrote:
> >I have a feeling that we are dealing with a Race Condition on the
> AbstractPool.
> 
> quite Possible.
> 
> >I think we should make all Pools ThreadSafe.  This contract will make things
> >alot easier for people who are implementing pools in concurrent execution
> >environments (i.e. multithreaded).  In cocoon, I will explicitly synchronize
> >the get() and set() methods--but this is a temporary stop-gap until we make
> >the Pool implementation thread-safe.
> 
> All pools used in a multithreaded environment should use ThreadSafePool.
> DefaultPool is for use in single-threaded environments.

In a server environment, there are very *few* single-threaded environments.
In my apps I try to incorporate at least some form of concurrency--the
headaches pay off in both percieved and measured performance.

However, it was extending AbstractPool as that seems to be the logical
choice to extend...  Unless we want to make an AbstractThreadsafePool
to make it explicit what to extend.

> 
> >I do think there is room for multiple different types of pools:
> >
> >* Hard resource limiting (Absolutely no more than X components)
> >* Soft resource limiting (May have more than X, but extras are destroyed
> when returned)
> >* No resource limiting (As extras are needed, they are created and
> maintained)
> 
> agreed ;)
> Cheers,
> 
> Pete
> 
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof."                   |
> |              - John Kenneth Galbraith               |
> *-----------------------------------------------------*
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org