cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Lewis" <...@ascii27.net>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Thu, 06 Jun 2002 21:38:42 GMT

<snip/>

>
> If you to change Transformer interface to return only
> XMLSource/ContentHandler, all the logic and state Transformer has moves
> into this XMLSource.
>
> Thus, XMLSource becomes heavy and Transformer light. Obviously,
> Transformer becomes ThreadSafe (which is good) and XMLSource must be
> made Poolable (its heavy, it is stateful).
>
> Instead of having one component we ended up with two. Please tell me I
> see things wrongly.
>

actually - you end up with one compoent, but it may consist of more than
one object. Bascially object != component. Only the transformer is a
componenet. But components are conceptually large, and may as a result
have any number of  other classes incolved in thier work. I have
implemented service frameworks in java before (though nothing the level of
comprehensiveness of Avalon) and this model works REALLY well.
It is true that some componeents may have objects that they pool though,
depending on the implementation. WE create several abstracts to extend for
handling that when creating a component.
<snip/>
>
> Two issues on this one:
>
<snip/>

The key here is being aware of the lifespan of the componenet you are
using. We used a default lifespan of a single request, but actually allow
you to "anchor" the compoenent to another object for its lifespan - when
that object went away, your component got cleanp-up/returned to the pool.
<snip/>

>
>> Anything that is more granular than that needs a
>> different treatment.
>
> What could it be?
>
in some cases similar mechnisms will be used, but there is a conceptual
line her eon component vs. object. I'm on this thread because this is an
area where I feel like I have personally made A LOT of the possible
mistakes on this path.
<snip/>
>
> Some transformers use instance of serializers to do its work. It could
> be looked up on startup and returned on shutdown (to speedup processing
> - right now manager.release() is quite expensive operation), and will
> not depend on request/response cycles.
>

different componenets can have different basis for lifespans...it should
be done with caution and justification, but it doesn't break anything. It
is a container issue hwo and when it reclaims it. Pooling per request is
one lifetime appraoch a container could take.
-- 
"The heights of genius are only measurable by the depths of stupidity."



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


Mime
View raw message