cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Lewis" <...@ascii27.net>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Thu, 06 Jun 2002 19:10:40 GMT
I've always maintained that the key difference between an object and a
component is granularity. Both can be reusable, but a component generally
represents a (reusable)  encapsulation of a conceptually larger "chunk" of
logic/data than a typical object.

>> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>>
>> > 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.)
>
> 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
> that.
>
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org


-- 
"The heights of genius are only measurable by the depths of stupidity."



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


Mime
View raw message