cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Steuck <greg-avalon-...@nest.cx>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Thu, 06 Jun 2002 19:03:30 GMT
>>>>> "Leo" == Leo Sutic <leo.sutic@inspireinfrastructure.com> writes:

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

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

    Leo> As for whether this is efficient or not - that is not the
    Leo> issue. 

Wouldn't it be more IoCish to pass an instance of
ExpensiveButPooledComponent to the method as opposed to it acquiring
such instance on it's own?

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

If I am not mistaken you just described a component with PerThread
lifestyle policy, no?

Another alternative is you build an object along the lines:

class SomeMethodDoer {
   SomeMethodDoer(ExpensiveButPooledComponent) {
   } 

   someMethod() {
   }
}

And then build it (yes, explicit new) and call someMethod as many
times as you need.

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


Mime
View raw message