From cocoon-dev-return-27796-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Thu Jun 06 19:10:36 2002 Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 23437 invoked by uid 500); 6 Jun 2002 19:10:36 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 23426 invoked from network); 6 Jun 2002 19:10:35 -0000 Message-ID: <2474.128.159.142.62.1023390640.squirrel@oasyx.net> Date: Thu, 6 Jun 2002 15:10:40 -0400 (EDT) Subject: RE: [Design] ContainerManager is under fire--let's find the best resolution From: "Andy Lewis" To: In-Reply-To: <000901c20d8c$92506500$ac00a8c0@Gabriel> References: <003a01c20d8a$e79e89d0$0801a8c0@Lagrange> <000901c20d8c$92506500$ac00a8c0@Gabriel> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Reply-To: ajl@ascii27.net X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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