> From: Leo Sutic [mailto:[EMAIL PROTECTED]] > > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > > > > From: Leo Sutic [mailto:[EMAIL PROTECTED]] > > > > > > 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
