cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: Why does Action extend ThreadSafe ?
Date Fri, 10 Aug 2001 22:31:53 GMT
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

>
> > > Action is like DocumentRepository in Berin's excellent paper on Avalon :
> > > the DocumentRepository interface is designed to *allow* ThreadSafe
> > > implementations by having a single method but doesn't enforce it, and
> > > the DatabaseDocumentRepository implementor *decides* to actually be
> > > ThreadSafe.
> > >
> > > So, do you still want to keep ThreadSafe on the Action interface, or
> > > leave that decision to action implementors ?
> >
> > Well, I'll give you a -0 ;)
> Cool, that's better than a -1 ;)
> >
> > Giacomo
> >
>
>


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


Mime
View raw message