(Servlets, Thread safety) Protecting the session and context state

Question

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.

Answer 1

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.

Answer 2

And why are class (static) variables not thread-safe? Because all threads can access and modify (corrupt) that value?

Correct. If a member is static, one thread can set a value and another thread can set differently. As static is shared variable, the value set by first thread will be the same for another thread also.

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."

Even if you make some servlet implement SingleThreadModel, it will stop only those thread to executly simultaneoulsy which are trying to access that servlet. It can't stop all other servlets which do not implement SingleThreadModel from accessing context and session attributes. This is because context attributes are available all over the web application and anyone resource can access them and modify them.

Answer 3

bring a web app to its knees

Because the access to the service() method of the Servlet will be synchronized . This can be implemented in two ways , (1) block other request threads till the current thread completes execution of the service() , (2) Create new instance of the Servlet (or maintain a pool of Servlet instance) in the Container and each request invokes the service() of a separate instance. Both are resource intensive and non performant.

without protecting the session and context state

Because even though you synchronize access to the service() method of your particular Servlet which implements the SingleThreadModel . The access to the session and context are not synchronized . Code other than your Servlet are free to access HttpSession or ServletContext attributes.

Are they saying that it's not enough thread-safe to implement the SingleThreadModel?

Yes , even the class variables may not be thread safe , if the Container implements the model such that each thread uses a free Servlet instance from the pool.

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?

Absolutely.

If a Servlet implements the SingleThreadingModel, then why would you need to protect session state?

To protect the data stored in the HttpSession . 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.

class (static) variables not thread-safe

Because it is shared by all instances of a class.