• 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

Alternative to Single Thread model ?

 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,
I was reading the Servlet 2.4 spec when I came across thread safety in Servlets. From the spec,

The use of the SingleThreadModel interface guarantees that only one thread at a
time will execute in a given servlet instance’s service method. It is important to
note that this guarantee only applies to each servlet instance, since the container
may choose to pool such objects



I understand that If I implement Single thread model then the container may create more than one instance for each servlet as opposed to only one if i don't implement it.

I was just wondering, why isn't there a combination of both. The container creates multiple instances for each servlet and also take advantage of multi threading. This guarantees thread safety of servlets because each request will have a separate instance of the Servlet class. Why hasn't any container implemented such a model ?

I assume there are potential disadvantages to this model, can any of you list it out ? One disadvantage is creating servlet instances each time a request comes can be costly.
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What would the advantage of such a model be?
 
Anand Athinarayanan
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, our servlets can have instance variables and still be thread safe.
 
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And what would be the advantage of that?
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Anand Athinarayanan wrote:Well, our servlets can have instance variables and still be thread safe.


No they couldn't. In a hybrid approach, some instances may be shared across threads and you'd still have to write servlets to be thread safe. Unless you are talking about creating a new instance for each request.

I still see no advantages, as Tim asks.

In the 14 years I have been writing servlets, I've never missed instance variables. It's just a tiny amount of effort to make sure that servlets are written in a thread-safe manner.
 
Tim Holloway
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think a lot of people think that a servlet is a "program". It isn't. It's actually more like a specialized form of Stateless Session EJB, although it predates EJBs and is invoked by the webapp server instead of an RPC-style application function.

Or, if you prefer Windows terms, it's more like a functional component in a DLL.

While you can certainly define both member and class variables in a Servlet implementation class, there are J2EE constructs that do that and generally should be used instead. In particular, an instance variable usually functions better as a Session property. No threading issues, and each and every user gets a unique instance.
 
Anand Athinarayanan
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bear and Tim,
Thank you for your replies. Writing thread-safe servlets is more efficient than the alternative to single thread model.

While you can certainly define both member and class variables in a Servlet implementation class, there are J2EE constructs that do that and generally should be used instead



I've never seen a member variable in a Servlet before. What do you mean be J2EE constructs that do that ? Can you give me an example.
 
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think Tim means using other "components" within the Servlets, as member variables. For example, Java EE allows you to inject EJBs within the member fields of your servlet:


Setting that field is the responsibility of the Java EE container and it knows when to set it.
 
Tim Holloway
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jaikiran Pai wrote:I think Tim means using other "components" within the Servlets, as member variables. For example, Java EE allows you to inject EJBs within the member fields of your servlet:


Setting that field is the responsibility of the Java EE container and it knows when to set it.



Actually, I mean in general. Doesn't matter who sets them or how. It's very unsafe to have member variables, since not only are they not thread-safe, there's no actual reason why a webapp server couldn't construct multiple instances of the servlet class (at least in the original spec). And, of course, each one would have an independent and possibly conflicting set of member property values.

It's the difference between what you can do and what you should do.
 
Greenhorn
Posts: 12
Netbeans IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Bear Bibeault wrote:

Anand Athinarayanan wrote:Well, our servlets can have instance variables and still be thread safe.


No they couldn't. In a hybrid approach, some instances may be shared across threads and you'd still have to write servlets to be thread safe. Unless you are talking about creating a new instance for each request.

I still see no advantages, as Tim asks.

In the 14 years I have been writing servlets, I've never missed instance variables. It's just a tiny amount of effort to make sure that servlets are written in a thread-safe manner.




Here, you have mentioned hybrid approach. What does it exactly mean. I am new to j2ee concepts. just i studied about 4 approaches using which we can have Thread Safe servlets.
1. using all local variables
2. protected synchronised service() method
3. synchronised blocks
and 4. Implementing SingleThreadModel interface. ()
Which is mostly used approach? will you please explain? or is there any another approach which is being used?
 
Tim Holloway
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The preferred approach is not to single-thread at all. Single-threaded functionality scales badly.

Failing that, you can use synchronized methods in the servlet, although it's usually better to offload complex logic to a POJO business bean that the servlet references.

Another approach is to use Session EJBs, although not all webapp servers have built-in support for that (Tomcat, for example).

For long-running serial functions, construct an engine thread and have the servlet queue up work to the engine.

If by using "local" variables, you mean member variables, don't even think about it. As we've already mentioned, member instance variables are not inherently thread-safe.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic