cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Thu, 06 Jun 2002 19:01:31 GMT
> From: Leo Sutic [] 
> > From: Berin Loritsch []
> > 
> > > From: Leo Sutic []
> > > 
> > > 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.)

Hmm.  What we have here is a bad design.  Should the container
make up for your poor design?  Can you really get away with only
three instances in a pool with a web environment?  Honestly,
there is nothing in Cocoon that does what you are talking about.

You have something more than "I may want to implement this poor
design some day" that we can discuss?

What you described here is woefully innefficient, and you will
have to refactor it completely in the very near future.  Why not
discourage bad design?

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

A component is a reusable binary that observes a public interface.
All component implementations of a specific public interface are
interchangeable.  The Bridge pattern states that the implementation
observes an external interface--you can't have components without

However, the most successful components "do", not "represent".
It's a conceptual thing.  If you process a request by calling a
method on a component, then we are all good.  If you have a component
represent something and call multiple method calls on it, then
we run into the problems we are experiencing.

Now, a way to philisophically enforce the "do" vs. "represent"
concept is to call the components by a new name: services.  A service
is a type of component that "does" something or performs a service.

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

That is one way of handling what you are talking about without
writing a GC routine.

> > >      ...means a load of GC policy parameters for the client.
> > 
> > ? I don't get this at all.
> I meant "user", not "client". My bad.

It's still a container concern.

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

View raw message