> 
> Right - I understand that, unless your servlet implements SingleThreadModel,
> it is a multi-threaded object.

NO. Actually STM doesn't make your servlet non-MT at all. It only means
that one request goes to one INSTANCE of your servlet. The servlet engine
can still create multiple instances of your servlet and if you have a
static variable in there, you will need to syncronize it. STM is a bad
stupid thing and you should never use it. Learning MT is much better and
easier.

> I was just wondering if there was any advantage (or maybe a disadvantage) to
> having multiple multi-threaded objects processing requests instead of a
> single multi-threaded object. I'm not hugely familiar with the ins and outs
> of multi-threading.

I doubt it would help anything and would only add more complexity to
things so that is a major negative anyways.

> In the 2.1+ Servlet spec, for instance, there is one RequestDispatcher per
> servlet - would requests be dispatched more efficiently by having multiple
> dispatchers?
> 
> Sam

It wouldn't really make a difference. Look at the ScreenLoader...it is
as efficient as it is going to get. Also, it is necessary for the Turbine
servlet to control things so having multiple requests going through
multiple copies of Turbine servlet in memory really won't save you
anything.

Also Turbine has to support 2.0 and higher until Tomcat is more widely
tested and stable. Once Tomcat replaces JServ, then I will be willing to
drop 2.0 support.

Anyway, what are you trying to get at here? What exactly do you see as a
problem? The overall design of Turbine is about 3 years old now and is
well proven to work and be efficient. Unless you have a real problem, this
discussion is moot since nothing will be changing. :-)

-jon

-- 
Scarab -
      Java Servlet Based - Open Source 
         Bug/Issue Tracking System
        <http://scarab.tigris.org/>


------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Problems?:           [EMAIL PROTECTED]

Reply via email to