Referring to: Head First Servlets & JSP, page 204, third question:
Q. "The effect of implementing SingleThreadModel is virtually the same as synchronizing the service method. Both can bring a web app to its knees without protecting the session and context state."
What does this mean: "bring a web app to its knees without protecting the session and context state"? Are they saying that it's not enough thread-safe to implement the SingleThreadModel? Because even though only one thread at a time can be running at one servlet, this doesn't stop other servlets from accessing and mutating the context/session scoped variables? If a Servlet implements the SingleThreadingModel, then why would you need to protect session state? It only allows one thread at a time. Even if you open up a new browser window, the servlet wouldn't allow you to make two requests, I think. Maybe they mean that different Servlets with one thread at a time could still corrupt the context/session state if they don't synchronize on that state?
And why are class (static) variables not thread-safe? Because all threads can access and modify (corrupt) that value?
It's still a little vague to me.
Referring to: Head First Servlets & JSP, page 204, third question:
Q. "The effect of implementing SingleThreadModel is virtually the same as synchronizing the service method. Both can bring a web app to its knees without protecting the session and context state."
What does this mean: "bring a web app to its knees without protecting the session and context state"? Are they saying that it's not enough thread-safe to implement the SingleThreadModel? Because even though only one thread at a time can be running at one servlet, this doesn't stop other servlets from accessing and mutating the context/session scoped variables?`
This is correct.
If a Servlet implements the SingleThreadingModel, then why would you need to protect session state? It only allows one thread at a time. Even if you open up a new browser window, the servlet wouldn't allow you to make two requests, I think.
That is incorrect. You could have another tab, another window or whatever. You might not be able to access the same Servlet at the same time, because you might be blocked, but you could access another Servlet that also accesses the same Context or Session. And, according to the API, it is allowable to have multiple instances of the same Servlet serve multiple responses in different threads (the only restriction is that one instance can't server multiple threads).
Maybe they mean that different Servlets with one thread at a time could still corrupt the context/session state if they don't synchronize on that state?
And why are class (static) variables not thread-safe? Because all threads can access and modify (corrupt) that value?
There is nothing inherently more or less thread-safe about static variables than instance variables. But you have to understand how the values are protected and how the SingleThreadModel is implemented. If the SingleThreadModel is implemented by allowing multiple instances of the Servlet, each stuck on a single Thread, then the static variables would be shared among all instances and therefore accessible to their threads as well.
Regardless, I would think you should never use (non-final) static variables in the Servlet class because you don't control the Servlet's life cycle. It can be created, destroyed, and recreated as the container demands. So a value you put in the static variables may not be there when you next try to access it. And you should never use the SingleThreadModel because it is inefficient and doesn't really do its job, and it has been deprecated for a long time. So you definitely should not use them both together.