cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Thu, 06 Jun 2002 18:49:33 GMT


> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> 
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > 
> > Suppose you have a pool-max of 3:
> > 
> >    public void handleRequest () {
> >       someMethod ();
> >       someMethod ();      
> >       someMethod ();
> >       someMethod ();
> >    }
> 
> And this is different from the current state of affairs, how? 
> If a request requires 5 transformer instances, and you have 
> your pool max set to 3, you will still experience slow down.  
> This is no different than automatically releasing a component 
> when the request is handled.

The difference is this - with explicit release I can:
  
   public void someMethod () {
      component = manager.lookup (ExpensiveButPooledComponent.ROLE);
      ...
       manager.release (component); <<<<<<<<<<<< Added
this
   }

And thus not drain the pool, as I only really need 1 instance.

As for whether this is efficient or not - that is not the issue.
The point is that with a per-request GC, you will need to lookup
all components you require *at the start of the request* and then pass
those around as you process the request (to avoid too many lookups) - 
unless you  are really sure that you will not end up in a situation 
similar to the one I described. (That is, you repeatedly call
a method that does a lookup during a single request. It will never be 
as simple as the example: someMethod() will call someOtherMethod and 
so on until, 20 steps up the call stack, you have a lookup. And then,
20 more steps until the last method returns.)

> I am finding more and more what people are calling components 
> are nothing more than Objects that observe the Bridge 
> pattern.  They implement an interface, introduce a few 
> lifecycle methods, etc. If they are object then they should 
> be treated as such.

Then what is a component? A Facade?

> If a pooled object requires an explicit 
> return to a pool, than that decision should be made in the 
> GeneratorManager, or the TransformerManager, etc.  Not in the 
> core lookup mechanism.

What you propose is then that pooling is removed from
the container itself. Pooling will be done by first using a component
manager to lookup another manager, and then use that manager
to obtain an instance from the pool. Am I correct?

> >      ...means a load of GC policy parameters for the client.
> 
> ? I don't get this at all.

I meant "user", not "client". My bad.

/LS


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


Mime
View raw message