Re: AW: [C2]: Component Pooling and recycling

[Sam Ruby <ru...@us.ibm.com>]

Related conversation.

- Sam Ruby
---------------------- Forwarded by Sam Ruby/Raleigh/IBM on 02/26/2001
11:57 AM ---------------------------

Giacomo Pati <gi...@apache.org> on 02/26/2001 11:55:41 AM

Please respond to cocoon-dev@xml.apache.org

To:   cocoon-dev@xml.apache.org
cc:
Subject:  Re: AW: [C2]: Component Pooling and recycling



Carsten Ziegeler wrote:
> > Berin Loritsch [mailto:bloritsch@apache.org] wrote:
> >
> > Carsten Ziegeler wrote:
> > > > * Paul Russell wrote
> > > >
> > > > * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > > > > * Carsten Ziegeler (cziegeler@sundn.de) wrote :
> > > > > > > I would suggest to change the behaviour of 3. and 4. that
> >
> > Recyclable
> >
> > > > > > > sitemap components are always recycled and that Poolable
> > > > > > > sitemap components are alyways returned to the pool -
> > > > > > > regardless if they declare PoolClient or not.
> > > > > >
> > > > > > How do you propose doing the last?
> > > > >
> > > > > The ResourcePipeline currently gets the sitemap components
> >
> > out of the
> >
> > > > pool
> > > >
> > > > > and puts them back if they declare PoolClient. I would add at
that
> >
> > point
> >
> > > > > an additional test for Poolable and Recyclable. The
> > > >
> > > > SitemapComponentSelector
> > > >
> > > > > must be extended by a put-method() for this.
> > > >
> > > > Uhuh. Might make more sense to add the 'put' method to the
> > > > CocoonComponentSelector, which is where all the pooling code seems
to
> > > > be.
> > >
> > > Ohh, yes the CocoonComponentSelector is the one.
> > >
> > > > Other than that, I have no major problem with it. I still think the
> > > > Avalon ComponentManager interface needs changing so that it
contains
> > > > a 'put' method, however. Anything that can 'compose' a component
> > > > should
> >
> > be
> >
> > > > able to 'put' it back afterwards. Everything we're doing to get
> > > > around this looks like a hack to me.
> > >
> > > Yes, exactly. This hacking is the reason why I am asking first - I
> >
> > thought that I perhaps had overlooked something.
> >
> > > So I think, we should do the hack first and then when a corrected
> >
> > ComponentManager is available we can remove it.
> >
> > That was my thinking when I created the PoolClient interface.  I would
> > really like the ComponentManager/Selector interfaces to remain "pure".
> > Especially since that is the way they are cast in the whole of Cocoon.
> > Your proposed solution will cause us to be required to cast as
> > CocoonComponentSelector--which is not a guarantee.  We should lobby
> > Avalon for the change to the official interface--and use PoolClient
> > in the mean time.
>
> Ok then, this means using PoolClient instead of Poolable everywhere and
> everything works fine.
>
> What about the Recyclable components? Is it correct, that a Recyclable
> component can be used without Poolable (or PoolClient) ? If so, who is
> responsible for calling recycle() ?

IIRC the Recyclable interface extends Poolable.

Giacomo (still 194 mail to read from this list :)

>
> Carsten
>
>
> C
>
>
> ---------------------------------------------------------------------
> 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