This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes Does SingleThreadModel ensure thread-safety? 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 » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "Does SingleThreadModel ensure thread-safety?" Watch "Does SingleThreadModel ensure thread-safety?" New topic
Author

Does SingleThreadModel ensure thread-safety?

S Subramonyan
Ranch Hand

Joined: Aug 26, 2004
Posts: 52
Hi,

Consider the servlet below:

public class MyServlet extends HttpServlet implements SingleThreadModel
{

int count = 0;

public void service(...) throws ...
{

System.out.println("You are visitor number .." + count++ );

}
}

Is it thread-safe or not?
Sekhar Kadiyala
Ranch Hand

Joined: Feb 17, 2004
Posts: 170
Yes it is, as it has only instance variables. Implementing SingleThreadModel interface ensures that only one thread can run service method at a time

1. Local variables are always thread-safe
2. Instance variables are thred-safe when the class implements SingleThreadModel interface
3. Class (or static) variables are never thread safe
4. Request, Response variables are thread-safe based on conditions like no threads are being run from Post/Get methods


PMP CSQA SCJP SCWCD SCBCD INS 21 INS 23
Bryan Basham
author
Ranch Hand

Joined: Apr 30, 2001
Posts: 199
The point of the SingleThreadModel interface is that it "Ensures that servlets handle only one request at a time." (javadocs)

This statement is a bit ambiguous because the container may implement that behavior in several different ways. One strategy is to have only one instance of that servlet and queue each request through it one at a time. Clearly such a strategy would imply that the servlet is "thread-safe" by the fact that only one request thread will execute the service/doGet method at any time. In other words, there is no concurrency. This strategy has the obvious drawback of poor throughput and ultimately poor scalability.

Another possible strategy is to create a pool of servlet instances in which each instance processes a single request thread at a time. Again, only one thread is executing in a given servlet instance so this strategy is also "thread-safe". However, the semantics of you counting servlet has been disrupted by the container. The original semantics (from the developer's prespective) is "count every hit to this servlet and display that count to the user". But in this container strategy, the original semantics is destroyed because the user can get a different answer depending on which instance of the counting servlet processes that user's request because each servlet instance has a unique value of the 'count' variable. The 'count' instance variable no longer counts the hits to the "counting servlet" but rather to that instance of the counting servlet. Make sense?

In servlet v2.4 spec, the SingleThreadModel interface has been deprecated for these very reasons: poor scalability of the one-at-a-time strategy and disruption of servlet semantics in the pooling strategy. Do not use the STM interface in your webapps. Instead, learn the challenging art of concurrency programming and DIY (do it yourself). I recommend Doug Lea's book Concurrent Programming in Java which is a difficult read, but very useful.

BTW, I will leave you with a thought problem... In the pooling strategy, you could make the 'count' instance variable into a class (or static) variable which would be shared among all pooled servlet instances. Here's the thought problem: Why does STM fail to work (keep the servlet thread-safe) in this scenario?

HTH,
Bryan
Sekhar Kadiyala
Ranch Hand

Joined: Feb 17, 2004
Posts: 170
Because the moment you make the 'count', a class variable, only one copy of the variable is maintained it will be available to all the instances of that class. So when 2 concurrent requests come to dispatcher, it will (has to) create two instances of this class and assign each one of them to two different threads. Obviously both the threads can access this 'count' variable and mnaipulate the data.
Chengwei Lee
Ranch Hand

Joined: Apr 02, 2004
Posts: 884
I thought the SingleThreadModel was out for SCWCD 1.4? Also, its deprecated as well?


SCJP 1.4 * SCWCD 1.4 * SCBCD 1.3 * SCJA 1.0 * TOGAF 8
S Subramonyan
Ranch Hand

Joined: Aug 26, 2004
Posts: 52
Yes, its deprecated in 1.4. We were talking about 1.3.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Does SingleThreadModel ensure thread-safety?