• Post Reply Bookmark Topic Watch Topic
  • New Topic

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

 
Ryan McClain
Ranch Hand
Posts: 153
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65524
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also be aware that SingleThreadModel has been long deprecated. It should never be used in new code.
 
Ryan McClain
Ranch Hand
Posts: 153
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So a Session is essentially a conversation between a client and a server, regardless of where the client requests come from (Servlets, JSPs, etc.)?
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!