aspose file tools*
The moose likes Servlets and the fly likes What makes servlet thread safe? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "What makes servlet thread safe?" Watch "What makes servlet thread safe?" New topic
Author

What makes servlet thread safe?

Tarun Oohri
Ranch Hand

Joined: Feb 20, 2013
Posts: 175
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 !!!
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41461
    
  51
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.


Ping & DNS - my free Android networking tools app
Tarun Oohri
Ranch Hand

Joined: Feb 20, 2013
Posts: 175
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!!!
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60975
    
  65

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.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Daniel Val
Ranch Hand

Joined: Jan 09, 2012
Posts: 44
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
Marshal

Joined: Mar 22, 2005
Posts: 41461
    
  51
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.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16011
    
  19

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41461
    
  51
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

Joined: Jun 25, 2001
Posts: 16011
    
  19

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
Marshal

Joined: Mar 22, 2005
Posts: 41461
    
  51
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What makes servlet thread safe?