cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: creating Overflow Resource
Date Thu, 19 Apr 2001 16:02:18 GMT
giacomo wrote:
> On Thu, 19 Apr 2001, Berin Loritsch wrote:
> > giacomo wrote:
> > >
> > > I think I've found the reason why C2 creates masses of Overflow
> > > Resources from JaxpParser. The JaxpParser itself states that it is
> > > ThreadSafe but extends AbstractXMLProducer which is Recyclable. The
> > > DefaultComponentHandler for this class first checks if it is Poolable
> > > (note that Recyclable exteds Poolable) and create a pool for it. This
> > > leads to the creation of new instances whenever a parser is lookup()ed.
> > > On the other side when the parser is released to the manager it is
> > > passed back to the handler which examines the interfaces implemented by
> > > the parser. The hnandler first tests if it implements ThreadSafe, (which
> > > the JaxpParser it does, and thus does not put it back to the pool.
> > >
> > > First we have to clean up the interfaces of the JaxpParser.
> > >
> > > Second, Berin, could you double check if the sequence of interface
> > > checks in the component management system in Avalon is correct?
> >
> > The affects of implementing conflicting interfaces like ThreadSafe,
> > Poolable, and SingleThreaded is undefined according to the Avalon Spec.
> > The interface definitely needs to be cleaned up.
> >
> > The way the ComponentHandler (the class that enforces the lifecycle
> > for a Component) works, is that it makes the assumption that the
> > class only implements one of the lifestyle (ThreadSafe, Poolable,
> > and SingleThreaded) interfaces.  If it extends Poolable, it creates
> > a pool.  This is usually the first check.  If it is ThreadSafe,
> > it will instantiate an instance of the class and hold it until the
> > class is disposed.  Finally if the Component is SingleThreaded, it
> > acts like a simple factory.
> This is not always the case. Take the Actions which extends
> ThreadSafe. But if someone writes a Action which can't be ThreadSafe
> (whatever the reason is) it should be able to "downgrade" the action to
> Poolable and the component management system should be able to take
> that into account, right?

I thought the contract with Actions stated that they _must_ be made
threadsafe and reentrant.  If this is not the case, then the ThreadSafe
interface should _not_ be included in the interface that describes an

In all reality, no work interface should extend a lifestyle interface
unless by the contract of the API it _must_ be enforced that way.
The decision of the lifestyle of a component should be done at the last
possible moment (much like making methods "final" in Java).  Once set,
they should never be over-ridden.  The ambiguities that arise over
lifestyle conflicts should be avoided if at all possible.

If we need to change the interface of some of the work interfaces to
not explicitely determine it's lifestyle, then let's do that.  The
Action interface is a prime example of something where if you don't
want it ThreadSafe, then the work interface should not specify it
that way.  The SitemapComponent is a prime example of something that
*requires* all implementing classes to be Poolable or SingleThreaded
(preferably Poolable).

The lifestyle and work interfaces are separate concerns, and should
only be merged when you are sure of the contract (e.g. with the
final implementation, or enforcing a contract in the interface).

To unsubscribe, e-mail:
For additional commands, email:

View raw message