This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes SingleThreadModel Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "SingleThreadModel" Watch "SingleThreadModel" New topic
Author

SingleThreadModel

Panagiotis Varlagas
Ranch Hand

Joined: Nov 27, 2000
Posts: 233
SingleThreadModel is getting deprecated as of J2EE 1.4 and I've never used it in my life, nor do I intend to do so. But, there is something that is bugging me about it. And that is what was the reason it was put in there (i.e. in the API) in the first place.
From the Servlet spec, we have that, if the servlet does NOT implement SingleThreadModel, then "the servlet container must use only one instance per servlet declaration". That's neat: You have potentially N concurrently running threads, all executing the same piece of code (the service() method).
At another place in the spec it reads: "It is strongly recommended that developers not synchronize the service method [...] because of detrimental effects on performance". That's also cool; makes sense: you don't want to serialize your potentially N requests!
So, it seems to me, that SingleThreadModel has been put out there by Sun, to provide some way of handling concurrent requests that want to access critical sections of code, without having to resort to serialization. So, they came up with the SingleThreadModel idea, where, if the API implementor (app server vendor) feels like it (it is not enforced by the spec), they may "satisfy this requirement (that there is only one request thread at a time in the service method) by maintaining a pool of servlet instances".
So, the servlet container instantiates N instances of my servlets to serve my N concurrent requests. Each request thread has its own "private" servlet serving it. And my question is: if the critical section of code, for which all this SingleThreadModel fuss has been started to begin with, was accessing a resource in my system that only a single entity may access at a time, don't I lose anyway? All my N servlets instances will access the resource in an unsynchronized manner and there will be mayhem.
It seems to me that, if you have a resource that can be accessed by only one guy at a time, then SingleThreadModel is not the solution, but the solution is to redesign your system so that there are no such resources!
Am I perhaps missing something here?
Am I viewing the issue too simplisticly? Your comments/explanations on this issue would be greatly appreciated.
Bill Skrypnyk
Greenhorn

Joined: Jul 04, 2003
Posts: 4
I think you pretty much nailed it. Although, you don't even have to go as far as resources. Even your own application or session-scope variables are in danger.
eric mcentee
Ranch Hand

Joined: May 02, 2001
Posts: 66
Near the end of the Java Servlet Tutorial at Servlet Tutorial it states that you should follow the paradigm of synchronizing critical sections of code.
The example they give looks like this:
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: SingleThreadModel