aspose file tools*
The moose likes Servlets and the fly likes when to use SingleThreadModle Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "when to use SingleThreadModle" Watch "when to use SingleThreadModle" New topic
Author

when to use SingleThreadModle

Kalpesh Soni
Ranch Hand

Joined: Jan 02, 2001
Posts: 312
Is there ANY good usecase where one should use SingleThreadModel
protecting data using synchronized methods/blocks is always possible.
Then why use it ?
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
SingleThreadModel should be avoided like the plague. Even though it guarantees only a single thread can access a Servlet instance, it does not guarantee thread-safe access to other Servlet resources such as the ServletContext and HttpSession. This means that even when implementing SingleThreadModel the developer cannot completely ignore threading.
For these reasons, the SingleThreadModel has been deprecated in Servlet 2.4, though in reality it fell out of favor long ago.
Panagiotis Varlagas
Ranch Hand

Joined: Nov 27, 2000
Posts: 233
The official word... (Servlet Spec, v2.3).
Does this make sense to you?
If it is does, please share with us too...
Thx.
=================================================
SRV.2.3.3.1 Multithreading Issues
A servlet container may send concurrent requests through the service method of
the servlet. To handle the requests the developer of the servlet must make adequate
provisions for concurrent processing with multiple threads in the service method.
An alternative for the developer is to implement the SingleThreadModel
interface which requires the container to guarantee that there is only one request
thread at a time in the service method. A servlet container may satisfy this
requirement by serializing requests on a servlet, or by maintaining a pool of servlet
instances. If the servlet is part of a web 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.
For servlets not implementing the SingleThreadModel interface, if the
service method (or methods such as doGet or doPost which are dispatched to the
service method of the HttpServlet abstract class) has been defined with the
synchronized keyword, the servlet container cannot use the instance pool
approach, but must serialize requests through it. It is strongly recommended that
developers not synchronize the service method (or methods dispatched to it) in
these circumstances because of detrimental effects on performance.
Kalpesh Soni
Ranch Hand

Joined: Jan 02, 2001
Posts: 312
Is it ABSOLUTELY necessary for a servlet container to make only one instance of servlet if it does not implement SingleThreadModel ? why ?
Panagiotis Varlagas
Ranch Hand

Joined: Nov 27, 2000
Posts: 233
Yep, Chris is right:
"javax.servlet
Interface SingleThreadModel
Deprecated. As of Java Servlet API 2.4, with no direct replacement. ..."
I will post this to the SCWCD forum too, but it seems to me that SunEd might want to "deprecate" it from the SCWCD exam objectives. By it being there, people learn about it and may be tempted to use it.
Panagiotis Varlagas
Ranch Hand

Joined: Nov 27, 2000
Posts: 233
> Is it ABSOLUTELY necessary for a servlet container to make only one instance of servlet if it does not implement SingleThreadModel ?
Yes.
> why ?
If I wanted to be pedantic I would say "Because the spec says so" (see excerpt from Servlet v2.3 spec at the very end of this post). However,
the rationale behind what the spec dictates, is (my conjecture) that we don't want to waste memory (at least by default) for keeping multiple servlet objects in memory. If you remember what was/is touted as the competitive advantage of Servlets vs CGI technology is the "single process, single instance" concept vs the CGI "multiple processes (one per request), multiple instances". But this is just my conjecture, haven't been the master mind behind architecting Servlet API...
=================================
"For a servlet not hosted in a distributed environment (the default), the servlet
container must use only one instance per servlet declaration. However, for a servlet
implementing the SingleThreadModel interface, the servlet container may
instantiate multiple instances to handle a heavy request load and serialize requests
to a particular instance."
Panagiotis Varlagas
Ranch Hand

Joined: Nov 27, 2000
Posts: 233
To second Chris' warning about avoiding SingleThreadModel like the plague. Here is a paragraph from an excellent book on perf. tuning.
("Performance Analysis for Java™ Web Sites
By Stacy Joines, Ruth Willenborg, Ken Hygh")
"The servlet specification does provide a single-threaded alternative. By implementing the javax.servlet.http.SingleThreadModel interface, your servlet becomes single-threaded. This means the application server creates an instance of your servlet for each simultaneous request. If you've never written a multi-threaded application before, you might feel tempted to use the single-threaded model. Don't do it! The single-threaded model does not perform well, particularly in high-volume web sites nor does it scale well. In this model, each request operates within its own fully instantiated servlets. This requires more memory and related overhead than the multi-threaded model. While the single-threaded model might seem like a shortcut, it is actually a performance dead end. Take the time and learn how to write good multi-threaded servlets instead."
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: when to use SingleThreadModle