cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [C2] Problem with component pools.
Date Fri, 23 Feb 2001 17:34:04 GMT
Paul Russell wrote:
> 
> * 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?

Quick and easy one:

Simply use a different class.  In other words why not have a PngSvgSerializer
and a JpegSvgSerializer that wraps up the configurations necessary for explicitly
making it use the different formats.  That is the _easy_ way.

Another simple and easy method is a wrapper that lets the Pool "mark" the client
silently to the end user.  Although without moving to JDK 1.3 and the Proxy
interface, this would quickly become an unweildy solution.

Mime
View raw message