This is inherent in the way a servlet engine works.
When a servlet is first called (or when the servlet engine starts, depending on the settings in web.xml) a single (or multiple, depending on server options and configuration in some servlet engines) instance of a servlet class is created.
From this instance multiple threats are launched when simultaneous requests need to be handled, one threat for each request (think of the service() method as a run() method in a multithreaded application).
Therefore each of those threads (and thus all requests) will have access to the same instance variables!
See this thread from a few weeks ago for more details.
Google: servlet "best practices"
you should get a lot of useful information.
Originally posted by Kevin Jones:
But remember that SingleThreadModel is deprecated in the 2.4 specification
I just would like to ask a question... The SingleThreadModel is deprecated in Servlet 2.4 Spec, but the JSP page directive still has the attribute "isThreadSafe"... As far as I know, if we set that attribute's value to be false, then the generated servlet class will implement the SingleThreadModel, won't it? So does it mean that the generated servlet will still contain the deprecated interface implemented?
So I just would like to know if there is any other way to avoid the deprecated interface in the generated servlet....
Thank you, Mr.Kevin...
Indicates the level of thread safety implemented in the page. If false then the JSP container shall dispatch multiple outstanding client requests, one at a time, in the order they were received, to the page implementation for processing. If true then the JSP container may choose to dispatch multiple outstanding client requests to the page simultaneously. Page authors using true must ensure that they properly synchronize access to the shared state of the page. Default is true. Note that even if the isThreadSafe attribute is false the JSP page author must ensure that accesses to any shared objects are properly synchronized., The objects may be shared in either the ServletContext or the HttpSession.
The JSP 2.0 spec doesn't require that the SingleThreadModel interface is used (although it certainly is implied). The isThreadSafe attribute is meant to inform a container that a JSP needs to handle requests one at a time -- which should never be something you have to do. If a generated servlet implements the SingleThreadModel interface is up to the specific container that generates your servlet.
A pretty good way to ensure you never end up with a generated servlet that implements SingleThreadModel is to never set the isThreadSafe attribute to false.
If you are interested in why SingleThreadModel is bad (and why it was originally made) and other gotchas similar to it, check out Kevin's and my book. We devote a whole chapter to maintaining state in a web application, which deals with the SingleThreadModel issue and similar issues, and all of the other chapters are packed with helpful tips, things to avoid, and good practices.
Originally posted by Jayson Falkner:
We devote a whole chapter to maintaining state in a web application, which deals with the SingleThreadModel issue and similar issues, and all of the other chapters are packed with helpful tips, things to avoid, and good practices.
Thank you for your great explanation on SingleThreadModel and by the way, does the book discuss about the best practices for building web application, optimization and performance issues? If so, is it somehow categorized into advance level books???
Thank you again for your explanation...