cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Russell <p...@luminas.co.uk>
Subject Re: [C2] Problem with component pools.
Date Fri, 23 Feb 2001 17:27:38 GMT
* 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

Mime
View raw message