Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

What is the approach for enabling thread safe servlets  RSS feed

 
JiaPei Jen
Ranch Hand
Posts: 1309
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marty, I just read your comments:

Never use SingleThreadModel. As discussed at length in the book, it has grave deficiencies (and is in fact deprecated in servlets 2.4/JSP 2.0)....

What is the approach for enabling thread safe servlets? Do I use synchronization? But, synchronization will probably create a bottleneck because only one thread can run the doGet() at any instant of time.
 
Eric Sexton
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Number one is making sure that being threadsafe is a necessity. If you do not have instance variables then you don't need to worry. Local vars are not persistent betweent requests, so you don't care about them. If you do have instance variables, you then need to decide if those intance variables need to be kept perfectly clean. If it's a counter, do you really care about that being kept threadsafe? Probably not.
I use syncronization in the rare instances that I need to keep a servlet threadsafe. Yes technically it does create the bottleneck potential. The trick is keeping those sync'd blocks as small as possible. Don't synchronize the whole method. Just synchronize the small parts that need to be kept safe.
[ November 12, 2003: Message edited by: Eric Sexton ]
 
Marty Hall
Author
Ranch Hand
Posts: 111
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the approach for enabling thread safe servlets? Do I use synchronization? But, synchronization will probably create a bottleneck because only one thread can run the doGet() at any instant of time.

Yes, use explicit synchronized blocks. Never use SingleThreadModel or <%@ page isThreadSafe="false" %>. There is a long discussion of the reasons for this in the book (with examples), but it boils down to two reasons:
  • If the server implements SingleThreadModel by queueing up all the requests to the servlet, you get really bad performance in high-traffic servlets for precisely the reason you mention above. (BTW, I believe "queueing" has the most consecutive vowels of any word in the English language.)
  • If the server implements SingleThreadModel by having a pool of instances (each of which handle only a single request at a time), then you probably have not prevented the race condition, which in most cases involves concurrent access to something stored in an instance variable (field) of the servlet.


  • However, I am not suggesting that you synchronize the entire doGet method! Start your synchronized block before you read the shared/persistent data, and end it after you finish modifying the persistent data. If possible, make sure that this block does not include I/O. In particular, the calls to response.getWriter and especially out.println (or to RequestDispatcher.forward) should be after the synchronized block ends.
    Similarly, don't use "this" as the argument for the synchronized block if you don't need to. For example, if you are worried about the obscure case of the same user hitting SUBMIT from two different browser windows at about the same time, do synchronized(session) {...}, not synchronized(this) {...}. That way, the obscure case is handled, but different users still can access the servlet concurrently.
    Of course, if there is no shared data, then you have no problem and don't need synchronization or SingleThreadModel or anything else.
    Cheers-
    - Marty
     
    Ko Ko Naing
    Ranch Hand
    Posts: 3178
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Marty Hall:

    but it boils down to two reasons:
  • If the server implements SingleThreadModel by queueing up all the requests to the servlet, you get really bad performance in high-traffic servlets for precisely the reason you mention above. (BTW, I believe "queueing" has the most consecutive vowels of any word in the English language.)
  • If the server implements SingleThreadModel by having a pool of instances (each of which handle only a single request at a time), then you probably have not prevented the race condition, which in most cases involves concurrent access to something stored in an instance variable (field) of the servlet.



  • Do u mean it is deprecated in Servlet 2.4, because of the above two reasons? So the coding practice previously done by developers need to be totally changed, according to those reasons that you have mentioned?
     
    Marty Hall
    Author
    Ranch Hand
    Posts: 111
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Do u mean it is deprecated in Servlet 2.4, because of the above two reasons? So the coding practice previously done by developers need to be totally changed, according to those reasons that you have mentioned?

    Right. The coding practice that many people used was always wrong, but now the spec committee realizes that SingleThreadModel is not salvageable, so they gave up and deprecated it.
    Cheers-
    - Marty
     
    It is sorta covered in the JavaRanch Style Guide.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!