This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
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.