• 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

What makes servlet thread safe?

 
Ranch Hand
Posts: 189
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Everyone
I am that fresher who wants to learn a lot in minimum amount of time. I went through core java, then servlet & Jsp...currently on Struts2.
But now when i see back and try to get my hands on basics of servlet....i am bowled out. Now realizing that java in not about studying , rather implementing !!!
Ok coming on to the topic ::
If we talk about Threads :

class A implements runnable{
public void run(String a, String b){
// some code }
}

class B {
public static void main(String []args){
A o = new A();
Thread t1 = new Thread(o);
Thread t2 = new Thread(o);
t1.start();
t2.start();
}
}
We can see that each thread t1 & t2 will get seperate set of a & b, because Thread Safety issues are with Instance & Static variables but not with method local variables .
Similarly the design pattern of servlet has been designed ?
Where Servlet class acts as class A & the doGet(HttpServletRequest req, HttpServletResponse res) act as run(String a, String b).
This way, when a request is sent to the server, container allocates a thread, when this thread runs doGet method of servlet class, it gets method local variables req , res ... Is this how a servlet is known to be thread safe ??
Please correct me where ever i am wrong .
Thanks in Advance !!!
 
Rancher
Posts: 43081
77
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Servlets are not generally thread-safe - they're thread-safe only if you make them so. Not using instance variables can (and should) be part of that, but by itself that is not sufficient.
 
Tarun Oohri
Ranch Hand
Posts: 189
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ulf Dittmer wrote:Servlets are not generally thread-safe - they're thread-safe only if you make them so. Not using instance variables can (and should) be part of that, but by itself that is not sufficient.


Thanks Dittmer, please tell me the way i am relating servlet above is right or wrong..Just want to know if i am thinking in right direction or not!!!
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guess I'd come at it from a different direction than Ulf: a servlet is thread-safe until you do something to make it not so. Adding instance variables is one way to make it not so. Adding unsynchronized read/write code to shared contexts is another. There are many ways you could trip up by referencing resources outside of what the container provides.
 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tarun Oohri wrote:

Ulf Dittmer wrote:Servlets are not generally thread-safe - they're thread-safe only if you make them so. Not using instance variables can (and should) be part of that, but by itself that is not sufficient.


Thanks Dittmer, please tell me the way i am relating servlet above is right or wrong..Just want to know if i am thinking in right direction or not!!!



Hi,

Although it is possible to have them configured in another way too, most of the people use the servlet configuration where there is only one instance of the servlet which is accessed by a lot of application threads.

The simplest way of making them thread safe: <b>ensure they don't store any state</b>. If you think well, you should not need any state anyway. So no attributes, and you are in the best thread safe situation.

Dan
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Daniel Val wrote:If you think well, you should not need any state anyway.


I disagree. Any web app of at least moderate complexity will have shared state, and most servlets will need access to it. That's not even problematic from a concurrency point, unless some of the shared state is mutable - that's the kind that needs to be handled especially.
 
Saloon Keeper
Posts: 27752
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
Ulf, there's a school of thought promoted by Red Hat that says that webapps should in fact be stateless. The reason for this is that for highly-scaled apps, you then have the ability to throw a URL request at an entire bank of servers and whichever one of them is up for grabs is just as capable of processing the request as any other, thus allowing maximum flexibility for load balancing and server outage recovery.

The logical webapp may or may not not be truly stateless, but the state isn't stuck to a specific instance of a physical webapp on a specific server.

For the rest of us, of course, the optimal place to store state is using as Session-scope objects. It is, as has been noted, extremely poor practice to store state information in instance or static variables within a servlet.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was talking more about app-specific state (not user-specific state), for which it would not be a problem keeping it on all web app servers.

I agree that for user-specific state a deliberate decision would need to be made about whether or not to have it, and how to handle it.
 
Tim Holloway
Saloon Keeper
Posts: 27752
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
Well, the front-line repository for application-specific state is Application Scope. So again, there's a preferred alternative to keeping state in the Servlet class or instance.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You misunderstood. I'm not talking about storing anything in the servlet. But access to shared mutable state needs to be synchronized no matter where it's stored.
 
reply
    Bookmark Topic Watch Topic
  • New Topic