• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

SingleThreadModel

 
Ranch Hand
Posts: 233
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:
 
reply
    Bookmark Topic Watch Topic
  • New Topic