Meaningless Drivel is fun!*
The moose likes Servlets and the fly likes thread safety in servlets Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "thread safety in servlets" Watch "thread safety in servlets" New topic
Author

thread safety in servlets

Daniil Sosonkin
Ranch Hand

Joined: Jan 15, 2004
Posts: 76
Hi,
I know this topic has been discussed here many times, but its not a question but more of a verification.
I have a servlet class, say MyServlet, which has field: private int number. When the thread pool is created for this servlet. Does it create several instances of this servlet or does use the same single instance in many different threads? I'm asking since if it has many instances and each thread runs a different instance (from a pool maybe) then there is synchronization risks for the private field. But if one instance is assigned to several threads at the same time to process request, then it poses a synchronization issue for fields.
I hope I make sense. But I'm still wary about servlet's fields which I usually use to pass HttpServletRequest/Response objects.
Thanks,
D.
Billybob Marshall
Ranch Hand

Joined: Jan 27, 2004
Posts: 202
It's up to the server implementation. But very likely it will use one instance by concurrent threads, hence the thread-safety issue. If you want a "private" field, you probably want that field for the particular session, so make it a session variable.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
When the thread pool is created for this servlet. Does it create several instances of this servlet or does use the same single instance in many different threads?
The container creates and initialises a single instance of the servlet, and passes all threads through it, so storing transient information in servlet instance variables is a huge risk.
I hope I make sense. But I'm still wary about servlet's fields which I usually use to pass HttpServletRequest/Response objects.
Could you explain a little more about what you mean by this, and what you find it useful for?
Personally, I have never felt the need to store request and response objects. Occasionally, I will pass them as parameters into a method, but mostly I prefer to pass around less-servlets-specific objects such as the request parameter Map and the response Writer. That way I can unit test my "helper" code without needing a servlet container.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Daniil Sosonkin
Ranch Hand

Joined: Jan 15, 2004
Posts: 76
Yeah, this creates the loads of issues for me. What about JSP? Since they are compiled into servlets, I assume they behave exactly the same. But in that situation it would create loads of problems with field declaration (negating its usefullness I would say). In fact, how does one go without them then, especially in JSP?
The reason for those is to have good code basically. For example, I have a logic that if a parameter hasn't been passed to the page then I can set it to "". So I create a method called getString(String name). Instead of passing HttpServletRequest to this method all the time, I'd be glad to set it as a private field and let the method work on its own.
Or I have an abstract class which handles user authentication in its doGet, then retreaves PrintWriter and passes the implementation to some abstract method. Instead of passing so much information (request, response, writer or maybe even user or something else application specific) it would be nice to have them as fields.
I guess I'll have to work on this issue. Does anyone have any suggestions about implementation.
In my JSP page I have fields such as user's Locale, user itself and which language one uses. This creates problems indeed.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
What about JSP? Since they are compiled into servlets, I assume they behave exactly the same. But in that situation it would create loads of problems with field declaration (negating its usefullness I would say). In fact, how does one go without them then, especially in JSP?
Are you sure that you are really using instance variables in your JSP?
To create an instance variable in a JSP you need to use the relatively uncommon "<%!" syntax, such as:
<%! String aName = "hello"; %>
Almost all JSPs that I have seen which define variables use the simpler "<%" syntax, such as:
<% String aName = "hello"; %>
to create a method-local variable (also known as a "stack variable"), which is generally thread safe.
For example, I have a logic that if a parameter hasn't been passed to the page then I can set it to "".
So far, so good. This is a pretty common requirement.
So I create a method called getString(String name). Instead of passing HttpServletRequest to this method all the time, I'd be glad to set it as a private field and let the method work on its own.
Here's where we differ, I guess. For unit testing and reusability purposes I prefer to do the absolute minimum of processing in the servlet itself. For something like this I would probably create a small "helper" class, maybe something like:

Now in my servlet I can just do:

Or I have an abstract class which handles user authentication in its doGet, then retreaves PrintWriter and passes the implementation to some abstract method. Instead of passing so much information (request, response, writer or maybe even user or something else application specific) it would be nice to have them as fields.
Likewise, if you balk at passing five or six parameters, I suggest you bundle them up into a single object, and pass that to your abstract methods. This also has the advantage that if you change your mind about what this bundled object contains, and what you can ask it to do, the signatures of your abstract methods and their implementors don't need to change.
In my JSP page I have fields such as user's Locale, user itself and which language one uses. This creates problems indeed.
If you have information relating to the current user, the most obvious place to store such information is the session context. By its nature, a session only refers to one user. This is just the sort of stuff the session context was invented for.
Does any of this make sense?
[ January 28, 2004: Message edited by: Frank Carver ]
john guthrie
Ranch Hand

Joined: Aug 05, 2002
Posts: 124
my two cents...
if you use the much-frowned-upon (and now deprecated?) SingleThreadModel marker, you could end up with multiple instances of a servlet (this *is* container dependent), but the each instance would run serially, so no thread issues with instance variables.
maybe that is what the first responder was talking about?
Daniil Sosonkin
Ranch Hand

Joined: Jan 15, 2004
Posts: 76
Thanks Frank, it really makes a lot of sense. I'll have to rethink my pages now; it was my mistake after all.
Vasilis Karas
Greenhorn

Joined: Mar 16, 2004
Posts: 24
Guys, I have another question about servlets, threads, instances and the container.
What happens when you create instances of servlets within another class..
For example I have a servlet.
I have a class that when instantiated has a member variable which is of type servlet. Does the container create another servlet? I'm looking at someone elses code and trying to explain to them that this isn't the way servlets were designed to work..besides pointing them to section 2.2 of the specification (2.3 Servlet API).
What actually happens when they do this--?
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12769
    
    5
My reaction to
I have a class that when instantiated has a member variable which is of type servlet. Does the container create another servlet? I'm looking at someone elses code and trying to explain to them that this isn't the way servlets were designed to work..besides pointing them to section 2.2 of the specification (2.3 Servlet API).

is YOW that looks like nothing but trouble. Certainly the only way a container will properly create a servlet instance is if it is invoked in the standard way, just creating an instance with new is not going to do it. At a minimum you would have to call init() with a valid ServletConfig.
If this other servlet class is so full of significant "business logic" that it has to be used this way, then major refactoring needs to be done.
Bill
 
 
subject: thread safety in servlets