cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Why does Action extend ThreadSafe ?
Date Fri, 10 Aug 2001 23:15:15 GMT

giacomo wrote:
> On Thu, 9 Aug 2001, Sylvain Wallez wrote:
> >
> > 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.

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.

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();

    // 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) {
    // 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.

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

Sylvain Wallez
Anyware Technologies -

To unsubscribe, e-mail:
For additional commands, email:

View raw message