Return-Path: 
 <cocoon-dev-return-27784-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 16713 invoked by uid 500); 6 Jun 2002 17:22:34 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 16702 invoked from network); 6 Jun 2002 17:22:33 -0000
Message-ID: <2200.128.159.142.62.1023384136.squirrel@oasyx.net>
Date: Thu, 6 Jun 2002 13:22:16 -0400 (EDT)
Subject: RE: [Design] ContainerManager is under fire--let's find the best
 resolution
From: "Andy Lewis" <ajl@ascii27.net>
To: <cocoon-dev@xml.apache.org>
In-Reply-To: <003401c20d7c$27489850$0801a8c0@Lagrange>
References: <004201c20d77$fa17d390$ac00a8c0@Gabriel>
        <003401c20d7c$27489850$0801a8c0@Lagrange>
X-Priority: 3
Importance: Normal
X-MSMail-Priority: Normal
Reply-To: ajl@ascii27.net
X-Mailer: SquirrelMail (version 1.2.6)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

I really like the philosophy behind what Berin is proposing here. You do
need to understand the lifecycle you are working in for component usage,
but how is that new....
>
>
>> From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>> >
>> > Berin,
>> >
>> > I am 75% for your new CM interface. The problem is point 4.
>>
>> Am I not a prophet?
>
> :)
>
>> > Assume you have a CM that automatically reclaims all
>> > components after each request. That is, for Cocoon, when the
>> > request comes in, the CM starts keeping track of what
>> > components have been taken out, and when the request has been
>> > processed, they are release()'d (or equivalent method).
>> >
>> > Now introduce pooled components.
>> >
>> >     If more than pool-max components are looked-up during
>> >     the request you are not performing well, as you empty
>> >     the pool.
>>
>> I thought I already did introduce pooled components.  It's
>> really simple.  The GC process for components releases
>> them--just like we currently do. The GC process is done
>> after the Response is committed.
>
> The scenario was when more than pool-max lookups had been
> done before the GC kicks in. Suppose you have a pool-max of 3:
>
>   public void handleRequest () {
>      someMethod ();
>      someMethod ();
>      someMethod ();
>      someMethod ();
>   }
>
>   public void someMethod () {
>      manager.lookup (ExpensiveButPooledComponent.ROLE);
>      ...
>   }
>

This is why I replied - please don't take offense, but why on earth would
you could it this way?!?! That sets of all kinds of personal warning flags
of programming practice for me. The framework can't and shouldn't make up
for an inefficient compoenent - and your example here looks to be exactly
that - very inefficient.
I'm am struggling with a real-world example of why you would NEED to do
something htis way...if you have one, please provide it...

> With an explicit release() this could be made not to drain the pool.
> With GC you can not, unless you set the timeout ridiculously low.
>
<snip/>



-- 
"The heights of genius are only measurable by the depths of stupidity."



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