Forums Register Login

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

+Pie Number of slices to send: Send
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.


1
+Pie Number of slices to send: Send
 

Ryan McClain wrote: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?



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.
+Pie Number of slices to send: Send
Also be aware that SingleThreadModel has been long deprecated. It should never be used in new code.
+Pie Number of slices to send: Send
So a Session is essentially a conversation between a client and a server, regardless of where the client requests come from (Servlets, JSPs, etc.)?
1
+Pie Number of slices to send: Send
 

Ryan McClain wrote:So a Session is essentially a conversation between a client and a server, regardless of where the client requests come from (Servlets, JSPs, etc.)?


Right. There is a cookie shared between them, with a fallback on an encoded URL parameter if cookies are disabled. As long as the client sends the cookie or url parameter, the session is shared. The client (browser) will usually send the same cookie for any requests from the same browser session, which almost always includes all tabs in the same browser window and most of the time includes new browser windows opened from the same root window, and even sometimes new browser windows opened from shortcuts and launchers. It can be pretty hard to get a two browser sessions to run simultaneously without using two different brands now adays.
Do not set lab on fire. Or this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 864 times.
Similar Threads
why need to synchronize the context and session attributes ?
Synchronizing the service method
Doubt in Thread Safe Servlet.
Single Thread Model
Is Sessions thread safe if servlet implement SingleThreadModel interface ?
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 19:23:56.