See intermixed.
Bo Xu wrote:
> Gokul Singh wrote:
>
> > ----- Original Message -----
> > From: "Bo Xu" <[EMAIL PROTECTED]>
> >
> > > * SingleThreadModel is non_multi-thread: so it is thread-safty but it
> > is not
> > > multi-thread-safty. But we also can think it is the safest way of
> > > multi-thread-safty :-)
> >
> > Single thread model is thread safe for the member variables of a class, but
> > as the container *may* instantiate more than one instance, it is not thread
> > safe for static variables, if any. Another fallback of this is if you are
> > using a non static member variable, each instance will have it's own copy
> > which may cause some problems e.g. if you used it to keep count of the
> > number of hits.
> >
> > > * I guess if we use SingleThreadModel, the Servlet container
> > > will have to work *harder*, and the efficacy is lower(because
> > > now for a Servelt class which implements SingleThreadModel,
> > > at any time, only zero/one client can access it ). and from
> > several
> > > emails, it is not good to use SingleThreadModel in a *real
> > > system*-> it is for testing(?) or other purpose.
> >
> > In a real environment, there can be N number of requests being processed
> > simultaneously by a servlet (each being a seperate thread). But if you use
> > SingleThreadModel, you limit the number of simultaneous request being
> > processed to the number of instances created by the container, which can
> > even be 1 !.
> >
> > > Bo
> >
> > Regds,
> > Gokul
> > [...]
>
> Hi Gokul, thanks for your email! :-) the following is my new understanding
> of SingleThreadModel after I read your email:
>
> # if my Servlet class implements SingleThreadModel, then for every Servlet
> definition,
> Servlet container will make a instance pool(which includes n instances) from
> my
> Servlet class.
>
More precisely, the servlet container has the *option* to create such a pool -- it
is not required. For example, Tomcat only creates one instance of your servlet per
servlet definition, even if it implements SingleThreadModel.
>
> # so now:
> * Servlet container will use one instance in this pool to make a thread
> for
> a new client accessing
> * and in any time( define by Newton, not by Einstein:-) ), we can not
> find
> two threads which are from the same instance.
> * we will not have n+1 threads in any time.
>
> # so in fact SingleThreadModel is still similar with multi-thread, but is a
> *limited*
> multi-thread-> every thread must from different instance in that pool.
>
The easiest way to understand what SingleThreadModel does is to pretend that you
declared your doGet() and doPost() methods to be synchronized -- within any one
instance of your servlet, there will be at most one request active at any given
time.
Obviously, this will have performance impact if your container provides "N"
instances and you get "> N" simultaneous requests.
>
> Is the above right? please give me some directions!
>
My advice: do not use SingleThreadModel. My reasoning is this:
* The performance impact described above, when you have more
requests than instances.
* The synchronization that is performed to implement SingleThreadModel
is not free -- but you pay that price on every single request even if it
is not needed.
* SingleThreadModel gives you the *llusion* of thread safety, because you
can use instance variables in your servlet to store per-request state
information safely. However, it does not protect you from other multi-thread
concerns:
- Static variables in your servlet class are still accessible from multiple
threads at the same time, if your container has instance pooling.
- Sessions and their attributes can still be accessed from multiple
requests simultaneously, so you still have to worry about it.
* Locking at the doGet() or doPost() method is more coarse-grained than
most applications really need. In most cases, you only really need to
lock around simultaneous access to shared resources -- but SingleThreadModel
doesn't give you that option.
* Instance pooling is not a required feature means that my
application will behave very differently on containers that provide instance
pools versus those that do not.
The best approach is to write your servlets in a thread-safe manner in the first
place -- then the only limit on how many simultaneous requests you can handle is
the maximum number of threads your JVM will support, with no artificial
restrictions because of synchronization at the per-servlet-instance level.
>
> Thanks in advance!
>
> Bo
> Dec.08, 2000
>
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
