This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
To be exact you implement the SingleThreadModel. This is not always thread safe. If you have declared static class variables only one copy of these will be available for all of the threads. Also, any use of session or context attributes will not be thread safe either. You could synchronize the block of code that access these but you would be taking a huge performace hit if there were any significant amount of users.
Correct, but as one exam software I use pointed out, that doesn't prevent your "single threaded" Servlet from launching its own threads. Those threads could then make your single Servlet instance not "thread safe". The bottom line for the exam is that implementing the SingleThreadedModel interface definitely does not guarantee your Servlet to be thread-safe.
I believe that it guarantees one thread per servlet instance but containers can pool instances of the servlet class.
Joined: Oct 26, 2002
I think it will depends attribute scopes that used , like if we use local var it will be thread safe Instance var will not ,and class var (static) will not too . I think the question a above missing to clarify the attribute scopes type. am i right?
Joined: Aug 08, 2002
I think the question probably, and I can only say probably, is to make you realize that implementing SingleThreadModel doesn't in and of itself guarantee thread safety. There are a number of gotchas that need to be kept in mind when using it. The Deshmukh book says one reason not to use it is: "a false sense of thread safety."