cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Steuck <>
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 <> 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:
For additional commands, email:

View raw message