cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: creating Overflow Resource
Date Thu, 19 Apr 2001 16:21:34 GMT


On Thu, 19 Apr 2001, Berin Loritsch wrote:

> 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
> Action.
>
> 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).

ok, convinced. We have to cleanup the interfaces from the jaxpParser
ASAP.

Giacomo


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message