avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: AW: [Bug?]: SingleThreaded vs. Poolable
Date Fri, 21 Sep 2001 13:42:27 GMT
Carsten Ziegeler wrote:
> 
> > Berin Loritsch wrote:
> >
> > Carsten Ziegeler wrote:
> > >
> > > Thanks for your explanation, Berin!
> > >
> > > I understand the difference, but - as I'm not a java expert - does
> > > not know, what makes a component SingleThreaded. Which circumstances
> > > must occur to declare a component so?
> >
> > Honestly, it is very rare that a compoent can't be used again.  However,
> > Xerces happens to make one.  I wish I new _why_ it was not reusable.
> > Basically, if the complexity of the component is such that it cannot
> > reset itself automatically, then you must implement it in a SingleThreaded
> > manner.
> >
> Ok, this means the component is only usable exactly one-time. This has in
> my opinion nothing to do with SingleThreaded. But ok, it's the way it is.
> 
> > The rest of the time Poolable or Recyclable will work.
> >
> > > One of the components I wanted to make singlethreaded is the JaxpParser
> > > in Cocoon2 (and that's actually the reason why I ask this question).
> > > I don't see any specific code in that class.
> >
> > JaxpParser is SingleThreaded--at least the last time I committed it was.
> > It should be implementing the SingleThreaded interface.
> >
> It still is, but if I understand you right, we could make the Jaxp parser
> Poolable when it instantiates a new (Xerces) parser object each time it
> it is get from the pool. This would slightly reduce object creation (
> and new configuration of the JaxpParser).
> Am I correct here.

You are correct.

> 
> Carsten
> 
> >
> > The mechanics are these:
> >
> > If a component implements a lifestyle interface (SingleThreaded, Poolable,
> > or ThreadSafe) it is used.  They are mutually exclusive--however there is
> > no Java mechanism to enforce this in the compiler--so it will not
> > complain.
> >
> > If a component does not declare any lifecycle interface then it is treated
> > as SingleThreaded.  This is not optimal, but it is the safest
> > assumption that
> > the CM can make.  Therefore implementing Poolable or ThreadSafe
> > are optimizations
> > to the run-time.
> >
> > >
> > > Carsten
> > >
> > > > Berin Loritsch wrote:
> > > >
> > > > Carsten Ziegeler wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I just wanted to make a SingleThreaded component poolable. Is this
> > > > > not allowed?
> > > >
> > > > They are not allowed.  Currently SingleThreaded marks interfaces that
> > > > cannot be reused, and must be used in one thread at a time.
> > Therefore,
> > > > they are manufactured by the Factory method.
> > > >
> > > > Poolable components (inherently only run in one thread at a time) can
> > > > be reused, therefore when one thread is done with it, it is returned
> > > > to the pool.
> > > >
> > > > Notice the distinction.
> > > >
> > > > > I get an exception from the excalibur component manager, which does
> > > > > the following test:
> > > > > >>>
> > > > >         if (SingleThreaded.class.isAssignableFrom(componentClass))
> > > > >         {
> > > > >             numInterfaces++;
> > > > >         }
> > > > >
> > > > >         if (ThreadSafe.class.isAssignableFrom(componentClass))
> > > > >         {
> > > > >             numInterfaces++;
> > > > >         }
> > > > >
> > > > >         if (Poolable.class.isAssignableFrom(componentClass))
> > > > >         {
> > > > >             numInterfaces++;
> > > > >         }
> > > > > <<<
> > > > > This means these interfaces can not combined. I agree that
> > > > > SingleThreaded and ThreadSafe are not possible and
> > > > > ThreadSafe and Poolable don't make sense, but
> > > > > Poolable and SingleThreaded seems ok to me.
> > > > > Or am I wrong?
> > > > >
> > > > > Carsten
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message