On Mon, 13 Aug 2001, Sylvain Wallez wrote:
>
>
> 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 ;)
You're welcome :-))
> 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 ?
This might be a solution. I'd take this approach.
> But I still have some questions (last ones for this thread, I promise)
You don't need to. I think others will benefit from this as well :)
> 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 ?
First they 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.
I don't get this ('for the sole purpose of implementing an action'?). An
action doesn't have to have an entry in the xconf file. Yes the xconf
file might grow to a respectable size for some projects/applications. It
depends how much Avalon you use.
> 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.
I'd go for a private CM for this. CMs can be arranged in a hierarchical
way.
> 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.
Do you think it is good practice to make the Actions "lifestyle" based
on a StateFullComponents "lifestyle" used by that Action? I still
think this is wrong.
Ok, It seems you'd like a simple vote like last time we'd discussed
map:parameter:
PLEASE COMMITERS vote on this:
Is it best to remove the TheradSafe interface from the Action interface?
>
> 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 :)
If writing "dead wrong" means "you are stupid" I really appologies for
that. I absolutely never mean this that way.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
