Rearchitected ComponentPool

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

I rearchitected the ComponentPool using the explicit lock object
in Avalon.  It is the same architecture used for JdbcConnectionPool,
and does not involve any waits.

The reason I did the rearchitecture is because I was suspecting a
deadlock in there.  This was not the case, but the code is cleaner
(no mixing of Avalon style and Cocoon style code), and easier to
grok by the average coder.

The ComponentPool does use resource a soft resource limiting
methodology.  My last attempt at creating a hard resource limit
resulted in a serious deadlock over time.  With a hard resource
limit, you must know EXACTLY how many of each type of component
you need.  With a soft resource limit, resources are created,
and overflow resources are destroyed.

You have the extra components when you need them, but you don't
hold on to the extra overhead for having them.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Rearchitected ComponentPool

[Giacomo Pati <gi...@apache.org>]

Quoting Berin Loritsch <bl...@apache.org>:

> I rearchitected the ComponentPool using the explicit lock object
> in Avalon.  It is the same architecture used for JdbcConnectionPool,
> and does not involve any waits.
> 
> The reason I did the rearchitecture is because I was suspecting a
> deadlock in there.  This was not the case, but the code is cleaner
> (no mixing of Avalon style and Cocoon style code), and easier to
> grok by the average coder.

I've read the commit mail and it indeed looks clearer to me, too. Great work, 
thanks.

Giacomo

> 
> The ComponentPool does use resource a soft resource limiting
> methodology.  My last attempt at creating a hard resource limit
> resulted in a serious deadlock over time.  With a hard resource
> limit, you must know EXACTLY how many of each type of component
> you need.  With a soft resource limit, resources are created,
> and overflow resources are destroyed.
> 
> You have the extra components when you need them, but you don't
> hold on to the extra overhead for having them.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org