Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15615.45570.748838.983738@slab.corp.buildpoint.com>
Date: Thu, 6 Jun 2002 12:03:30 -0700
From: Gregory Steuck <greg-avalon-dev@nest.cx>
To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Cc: <cocoon-dev@xml.apache.org>
Subject: RE: [Design] ContainerManager is under fire--let's find the best
 resolution
In-Reply-To: <003a01c20d8a$e79e89d0$0801a8c0@Lagrange>
References: <000001c20d83$6ca206f0$ac00a8c0@Gabriel>
	<003a01c20d8a$e79e89d0$0801a8c0@Lagrange>

>>>>> "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