"Jonnalagadda Pradeep." wrote:
> [...]
> Is this the reason to
> implement single thread model or are there any other compelling
> reasons to do so
> Ps let me know
> Thanks a lot
> Pradeep.
> [...]
Hi :-) the following is from Servelt spec2.2:
0
...
3.2 Number of Instances
By default, there must be only one instance of a servlet class per servlet
definition in a container.
In the case of a servlet that implements the SingleThreadModel interface, the
servlet container
may instantiate multiple instances of that servlet so that it can handle a heavy
request load while
still serializing requests to a single instance.
In the case where a servlet was deployed as part of an application that is
marked in the deployment
descriptor as distributable, there is one instance of a servlet class per
servlet definition per VM in a
container. If the servlet implements the SingleThreadModel interface as well as
is part of a
distributable web application, the container may instantiate multiple instances
of that servlet in
each VM of the container.
3.2.1 Note about SingleThreadModel
The use of the SingleThreadModel interface guarantees that one thread at a time
will execute
through a given servlet instance�s service method. It is important to note that
this guarantee only
applies to servlet instance. Objects that can be accessible to more than one
servlet instance at a
time, such as instances of HttpSession, may be available to multiple servlets,
including those
that implement SingleThreadModel,...
...
1
...
3.3.1 Loading and Instantiation
The servlet container is responsible for loading and instantiating a servlet.
The instantiation and
loading can occur when the engine is started or it can be delayed until the
container determines that
it needs the servlet to service a request.
First, a class of the servlet�s type must be located by the servlet container.
If needed, the servlet
container loads a servlet using normal Java class loading facilities from a
local file system, a remote
file system, or other network services.
After the container has loaded the Servlet class, it instantiates an object
instance of that class for
use.
It is important to note that there can be more than one instance of a given
Servlet class in the
servlet container. For example, this can occur where there was more than one
servlet definition that
utilized a specific servlet class with different initialization parameters. This
can also occur when a
servlet implements the SingleThreadModel interface and the container creates a
pool of
servlet instances to use.
...
2
...
3.3.3.1 Multithreading Issues
During the course of servicing requests from clients, a servlet container may
send multiple requests
from multiple clients through the service method of the servlet at any one time.
This means that
the Developer must take care to make sure that the servlet is properly
programmed for concurrency.
If a Developer wants to prevent this default behavior, he can program the
servlet to implement the
SingleThreadModel interface. Implementing this interface will guarantee that
only one
request thread at a time will be allowed in the service method. A servlet
container may satisfy this
guarantee by serializing requests on a servlet or by maintaining a pool of
servlet instances. If the
servlet is part of an application that has been marked as distributable, the
container may maintain a
pool of servlet instances in each VM that the application is distributed across.
If a Developer defines a service method (or methods such as doGet or doPost
which are
dispatched to from the service method of the HttpServlet abstract class) with
the
synchronized keyword, the servlet container will, by necessity of the underlying
Java runtime,
serialize requests through it. However, the container must not create an
instance pool as it does for
servlets that implement the SingleThreadModel. It is strongly recommended that
developers
not synchronize the service method or any of the HttpServlet service methods
such as doGet,
doPost, etc.
...
3
...
3.3.3.3 Thread Safety
A Developer should note that implementations of the request and response objects
are not
guaranteed to be thread safe. This means that they should only be used in the
scope of the request
handling thread. References to the request and response objects should not be
given to objects
executing in other threads as the behavior may be nondeterministic.
...
so from the above and several emails in Servlet-List, I guess:
* 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 :-)
* Servlet container will make a instance pool if we implement
SingleThreadModel even we only have one Servlet defination,
it means now we will have more than one *set* for every
instance field in our Servelt class for every Servlet definition.
* 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.
have a nice night :-)
Bo
Dec.06, 2000
___________________________________________________________________________
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
