Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Subject: Re: [RT] Alternatives to Poolable
From: Stephan Michels <stephan@apache.org>
To: Cocoon Developers <dev@cocoon.apache.org>
In-Reply-To: <4028B2D9.3010804@apache.org>
References: <4028B2D9.3010804@apache.org>
Content-Type: text/plain
Message-Id: <1076411677.2689.28.camel@verndeb>
Mime-Version: 1.0
Date: Tue, 10 Feb 2004 12:14:37 +0100
Content-Transfer-Encoding: 7bit

Am Di, den 10.02.2004 schrieb Sylvain Wallez um 11:30:
> Found a very interesting read at 
> http://www-106.ibm.com/developerworks/library/j-jtp01274.html?ca=drs-j0504
> 
> This articles explains the memory allocation and collection strategies 
> of modern JVM and show that object recycling and pooling can cause more 
> harm than good.

I was on a developer session during a Sun Network conference over
GC and object pools. The session clearly shows that the GC itself
managed pools the objects. And only heavy objects should be pooled
like Connections.
So the pools of avalon are more harmful, IHMO.

> I've always been worried by the fact that most of our stateful 
> components are Poolable (stateless ones are ThreadSafe) and not simply 
> SingleThreaded.
> 
> We make them Poolable because their creation cost is high. But why so? 
> Because the Avalon framework brings a lot of overhead to object creation 
> by going through the various lifecycle interface, and because each of 
> the created instances has to perform repetitive actions that could be 
> shared between the various instances. The main cost in this area is 
> parsing the configuration, which is the same for all instances of a 
> given component.
> 
> This leads to identifying something I would call "component fields" 
> which are between static fields (system-wide values for a class - 
> identical for the various component declarations using a class) and 
> instance fields (specific to a given instance).

I think the container should only work as factory, create a new object 
for every lookup, except for threadsafe components. The configuration
objects can be reused. Heavy objects can be stored the "Store".
And the release() methods can be droped.

For example in my application, at Im working on, I can create 5000
objects in 2ms. To find out in an object exists, and if it can reused
etc, will cost much more than 2ms.

So, +1 from my side.

Stephan.