>>>>> "Leo" == Leo Sutic <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
