Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Date: Fri, 23 Feb 2001 17:27:38 +0000
From: Paul Russell <paul@luminas.co.uk>
To: cocoon-dev@xml.apache.org
Subject: Re: [C2] Problem with component pools.
Message-ID: <20010223172738.K31530@hydrogen.internal.luminas.co.uk>
Reply-To: Paul Russell <prussell@apache.org>
References: <20010223161915.8296.qmail@web113.yahoomail.com>
 <3A969414.97F0ADF@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <3A969414.97F0ADF@apache.org>;
 from bloritsch@apache.org on Fri, Feb 23, 2001 at 11:47:16AM -0500
Sender: Paul Russell <paulr@hydrogen.internal.luminas.co.uk>

* Berin Loritsch (bloritsch@apache.org) wrote :
> Davanum Srinivas wrote:
> > 
> > Berin,
> > 
> > The "pools" Hashmap in both CocoonComponentSelector and DefaultComponentManager are keyed off the
> > just the Class and *NOT* the hint/role. The hint/role is ignored completely when we do a pools.get
> > or a pools.put. (For example in DefaultComponentManager lines 261 and 279)
> > 
> > The problem is with SVGSerializer which acts both as "svg2jpeg" and "svg2png". We always get the
> > same pool back as pools Hashmap uses the class SVGSerializer as the key.
> I see the problem.  This is much like the issue with ThreadSafe
> Components that was solved before.  In theory, every hint reflects a
> distinct Class.  In practice, we can have a single class that has
> differing configuration information.  It is more efficient to pool
> already set up components instead of virgin components--otherwise we
> loose the benefit of pooling.
> 
> Ok, We will make the ComponentManager/Selector be keyed off the
> role/hint every time.  This is the classic question of distinction:
> When is a Component a different Role/Hint and when is it the same
> Role/Hint?  The practical answer is this:
> 
> Any time a Component has to be made distinct (i.e. serialize to PNG
> vs. JPG, or the different Selectors we have floating around), it needs
> to be completely distinct by role or hint down to the instance
> retrieved from the ComponentManager/Selectors.

Indeed. One slight complication is that when we get the component back
in the release method, we have no way of determining its hint. I guess
the best way around this is to use a Map:

public void release(Component comp) {
	if ( comp instanceof Poolable ) {
		((ComponentPool)componentTracker.get(comp)).put(comp);
		componentTracker.remove(comp);
	}
	// [...]
}

..although this creates housekeeping complications when people forget to
release their components. We could use a weak reference to find out when
a component dies, and nuke the componentTracker entry for the component,
although this means keeping a Set full of references and regularly
checking the reference queue for dead components. Urgh. Any better
ideas?


Paul
-- 
Paul Russell                                 Email:   paul@luminas.co.uk
Technical Director                             Tel:  +44 (0)20 8553 6622
Luminas Internet Applications                  Fax:  +44 (0)870 28 47489
This is not an official statement or order.    Web:    www.luminas.co.uk