Does SingleThreadModel ensure thread-safety?

[S Subramonyan]

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]

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

[Bryan Basham]

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]

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]

I thought the SingleThreadModel was out for SCWCD 1.4? Also, its deprecated as well?

[S Subramonyan]

Yes, its deprecated in 1.4. We were talking about 1.3.