giacomo wrote:
>
> On Fri, 10 Aug 2001, Sylvain Wallez wrote:
>
> >
> > giacomo wrote:
> > >
> > > On Thu, 9 Aug 2001, Sylvain Wallez wrote:
> > >
> > <snip/>
> > > >
> > > > Now, about Action : the Action interface *allows* implementations to be
> > > > ThreadSafe, compared to interfaces like Generator or Transformer that
> > > > *forbid* it (for example because of setConsumer(), but there's no other
> > > > way with SAX).
> > > >
> > > > I don't discuss the statelessness of Action. What I'd like to achieve by
> > > > removing ThreadSafe from Action is keep the ability of having ThreadSafe
> > > > actions (the vast majority of them) while still allowing heavyweight
> > > > implementations to be pooled.
> > >
> > > I hope I've missunderstud you here. Components will not be pooled
> > > because they are heavywheigted but because they cannot be written in a
> > > thread safe way but they can be reused in a serializedd fashion.
> > >
> > IMO, Poolable means non thread-safe *and* heavyweight. If instanciating
> > a non thread-safe component isn't costly then a new instance can be
> > created for each request.
> >
> > But in fact, I misexplained the problem I wanted to outline : what if an
> > action (stateless, thus potentially ThreadSafe) relies on a non
> > thread-safe heavyweight object ? Should the action create and destroy a
> > new instance of that object at each request ? That would be bad for
> > performance : preferably, the object should be fetched from a pool.
>
> Make it a Component.
>
> > An important hypothesis here : this object is not a component handled by
> > the ComponentManager holding the action, and thus the action cannot get
> > an instance using CM.lookup().
> >
> > If Action does not extend ThreadSafe, each instance of our action can
> > hold an instance of the object. The action consequently inherits the
> > object's non-threadsafety, and can implement Poolable to benefit of
> > automatic pool management by the CM. That's what I would like to be able
> > to do.
>
> C'on, that's nonsens. You can always make a nonComponent a Component. In
> a project we've made byte arrays into components to avoid garbage
> collection. I'm still not conviced.
>
> >
> > To illustrate this, here are two examples : first, as it must be now
> > whith Action extending ThreadSafe, second with Action not extending
> > ThreadSafe and the implementation beeing Poolable.
> >
> > //-------------------------------------------------
> > // Action extends ThreadSafe
> > //-------------------------------------------------
> >
> > public class MyAction extends AbstractConfigurableAction {
> >
> > Configuration heavyConf;
> >
> > public void configure(Configuration conf) {
> > this.heavyConf = conf.getChild("heavy");
> > // action configuration
> > ...
> > }
> >
> > public void act(...) {
> > // costly creation of the heavy object
> > HeavyStatefullObject heavyObj = new HeavyStatefullObject();
> > heavyObj.configure(this.heavyConf);
> >
> > // do the action stuff using heavyObj
> > ...
> > // costly destruction of heavyObj
> > }
> > }
> >
> > //-------------------------------------------------
> > // Action doesn't extend ThreadSafe
> > //-------------------------------------------------
> > public class MyAction extends AbstractConfigurableAction
> > implements Poolable {
> >
> > HeavyStatefullObject heavyObj = new HeavyStatefullObject();
> >
> > public void configure (Configuration conf) {
> > this.heavyObj.configure(conf.getChild("heavy"));
> > // action configuration
> > ...
> > }
> >
> > public void act(...) {
> > // do the action stuff using this.heavyObj
> > ...
> > }
> > }
> >
> > Now, one could say that the action could remain ThreadSafe and
> > instanciate its own pool and manage it manually. But such actions will
> > loose the benefits of automatic pool management by the ComponentManager
> > and have an increased complexity.
> >
> > I hope the problem is clear now, and you understand my point of view.
>
> Your problem is you don't understand how to benefit from Avalon. You try
> to convince me to a solution which is IMO dead wrong. And Action is not
> a object holder. Look at this:
>
> public interface HeavyStatefullObjectComponent {
> String ROLE = "HeavyStatefullObjectComponent";
> HeavyStatefullObject getHeavyStatefullObject();
> }
>
> public class HeavyStatefullObjectComponentImpl
> implements HeavyStatefullObjectComponent,
> Configurable,
> Poolable {
> private HeavyStatefullObject heavyObj = new HeavyStatefullObject();
>
> public void configure(Configuration conf) {
> heavyObj.configure(conf);
> }
>
> public HeavyStatefullObject getHeavyStatefullObject() {
> return heavyObject;
> }
> }
>
> You can make this even generic and pool every objet you like. As said
> above, I'm still -1 to remove ThreadSafe from Action!
>
> Giacomo
>
Ok, your remarks led me to dig into Avalon component management (didn't
do it up to know, and it was mainly a blackbox), and I admit my example
was "dead wrong" for an Avalon-guru when I wanted it to be a little bit
provocative. Thanks for this ;)
So, the obvious way to implement an action that relies on a statefull
object is to wrap this object with a Poolable StateFullComponent which
is added to the CM and do simple lookup/release in the action, right ?
But I still have some questions (last ones for this thread, I promise)
if StateFullComponent isn't used elsewhere in the system, even if this
isn't the most frequent case.
Isn't it potentially dangerous to expose StateFullComponent (fully setup
with its configuration) to other Composable in the CM if they don't have
to know about it ?
Is it acceptable, for the sole purpose of implementing an action, to add
an additional entry in the .xconf file ? This file may rapidly grow and
become hard to manage, when the action can simply be defined in the
(sub)sitemap where it is used.
Or should we allow some components to be added to the local CM of each
sitemap through a .xconf near each .xmap ? This would also enforce
security by segmenting the visibility of components in a shared
environment (some are security-sensitive, like datasources).
To avoid adding StateFullComponent into the CM, a solution can be for
the action to internally manage it using a ComponentHandler. But this
isn't so satisfying : the ComponentHandler's lifecycle must be handled
manually (need to be careful and Avalon-skilled), and we're stuck to
ComponentHandler's handling strategy when the enclosing CM could have
defined its own custom one (e.g. Avalon and Excalibur CMs strategies are
very different). As an exercise, I updated ServerPagesAction to this
solution.
Another solution, if Action doesn't implement ThreadSafe (yes, still
believing in that), is for the action to adopt the "lifestyle" of the
underlying component (SingleThreaded, ThreadSafe, Poolable) and simply
act as an adapter to the Action interface. This way there are no
additional declarations in the CM, no manual handling of a
ComponentHandler, and the action is managed by the CM in a way suitable
for StateFullComponent.
What are your thoughts about all this ?
And thanks a lot, Giacomo, for the time you spend answering my posts,
even if some
of them contain "dead wrong" statements :)
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
