SingleThreadModel

[Joe Rossano]

The following question is from Sun's sample exam:
public class MyServlet extends HttpServlet
implements SingleThreadModel {
private static StringBuffer value = new StringBuffer("123");
public void doPost(HttpServletRequest req,
HttpServletResponse resp) {
System.out.println("Inside doPost");
}
}
Which statement is true?
A. Both variable value and variable req are thread safe.
B. Both variable value and variable req are not thread safe.
C. Variable value is thread safe and variable req is not thread safe.
D. Variable value is not thread safe and variable req is thread safe
Sun claims that the correct answer is A, however I think it is D. I thought that shared resources such as static class variables were not thread-safe. Comments anyone?

[Carl Trusiak]

I think the key here is the SingleThreadedModel Since this servlet will run single threaded, all class variables are safe from inadvertant changes from other threads.

------------------
Hope This Helps
Carl Trusiak, SCJP2
[This message has been edited by Carl Trusiak (edited July 30, 2001).]

[Joe Rossano]

Ah... I see it now. If the static field was public it would not be thread-safe. However, since it is private it can only be accessed from within this class. And since this class implements the SingleThreadModel interface, you are guaranteed that no two threads will execute concurrently in it's service() method.
"This interface (SingleThreadModel) does not prevent synchronization problems that result from servlets accessing shared resources such as static class variables or classes outside of the scope of the servlet." - Servlet Spec 2.3

[Tony Alicea]

What sample exam is this? The one that costs $50 for a 30 day subscription?
If not, which one?
Thanks!

[Carl Trusiak]

Hey Tony,
There is the free one which gives you 10 questions.

[This message has been edited by Carl Trusiak (edited July 30, 2001).]

[Tony Alicea]

Thanks, I took that one but it doesn't show any code question which is why I asked

[William Brogden]

I am not really happy with that A answer. SingleThreadModel just guarantees that only one thread at a time will use a particular instance of the servlet. It does not guarantee that the servlet engine won't create several instances.
Look at that quote from the Javadocs
"This interface does not prevent synchronization problems that result from servlets accessing shared resources such as static class variables or classes outside the scope of the servlet."
So even a private value should be vulnerable if there is more than one instance of the servlet object.
Bill

[Peter den Haan]

Answer A seems to be a pile of junk; if this is the general level than I'll be proud of failing the exam You are right, the SingleThreadModel is more or less a guarantee that multiple servlet instances will be created. If they are going to fiddle with "value" (note it's not final) then there's nothing threadsafe about that.
- Peter

[Sergey Opanasets]

see Servlet 2.3 specification SRV.2.2 and SRV.2.2.1
SingleThreadModel ensures that access to each instance of the servlet will be granted only to a single thread at any given time. So private variable is safe unless it is static. Since static variable is shared between all class instances.
Variable req is a method parameter so it is thread safe, in certain sence "It is safe if used within the method". However you should not give it to any other Thread since it may create problems see. Servlet 2.3 specification SRV.2.3.3.3
so correct answer is D

[Michael Fritz]

I think the trick here is that value is a StringBuffer object. The following is from the API docs for the StringBuffer class:
"String buffers are safe for use by multiple threads. The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved."
-Mike

[Sergey Opanasets]

I beleive that thread safeness in this case is directly linked to the fact that there is a single servlet instance that serves multiple client's request.
Just to give you a real life example, from long time ago. We were using ServletOutputStream as a private variable of the servlet class in order to avoid passing it as a parameter to a method within a servlet. THAT WAS TOTALLY WRONG. When we tested the servlet in multi-user simultaneous access mode we ended up with User B receiving output intended for User A. Since you can not guarantee who gets what because of the single instance of the servlet class, although class variable is private. When we've changed to a SingleThreadModel the problem was solved, but this was a "bad design" problem.
So, although StringBuffer is thread safe, as well as thousands other java classes out there, the behavior of the servlet is unpreictable, which is a big problem. And to this extent this is wrong design.
So unless it is a read-only/("final") variable it is dangerous to use it as a class variable.

[Peter den Haan]

Originally posted by Michael Fritz:
I think the trick here is that value is a StringBuffer object. [...] "String buffers are safe for use by multiple threads. [...]"

If that's the reasoning behind it, I still disagree. The fact that multiple threads won't corrupt the StringBuffer's internal data structures doesn't make storing it in a static variable threadsafe. When writing code working with the buffer, you will have to be constantly on the guard for threading issues. I wouldn't want to call the "value" variable threadsafe in any meaningful sense of the word.
- Peter

[Michael Fritz]

Originally posted by Peter den Haan:
When writing code working with the buffer, you will have to be constantly on the guard for threading issues. I wouldn't want to call the "value" variable threadsafe in any meaningful sense of the word.
- Peter

So what meaning are you giving to the word "thread-safe"? As far as I know, "thread-safe" simply means that two different threads can't modify an object at the same time and put it into an invalid state. It doesn't mean that one's code is well designed or takes all threading issues into account.

[Sergey Opanasets]

Hopefully the definition of thread-safeness will help to convince that static variables are not thread safe since they are shared between multiple instances of the class. Which means that you should explicitly synchronize it in the supplied example
see definition from Whatis. http://whatis.techtarget.com/definition/0,289893,sid9_gci331590,00.html
I would stress the part of the phrase which says "without unwanted interaction between the threads"
Regards

[Tony Alicea]

My $0.02:
It all depends on how the container handles this...
I heard many months ago (from an IBM Architect) that static variables were not to be used in servlets.
How does the Servlet Engine handle static variables of Servlet classes that implement the SingleThreadModel interface?
In 'normal' Java, we know that every object (instance) of the class will share the static variables as one common variable.
In a Servlet 2.3 compliant container, will the static variable of a SingleThreadModel Servlet be shared with the other instances (other instances? I thought it was implementing the SingleThreadModel...)
Inquiring minds want to know...""

[Sergey Opanasets]

Wow, wow, I think the discussion is going too far ;-)
Just in case, browsed through Servlet 2.3 specification. Sorry, No exclusions mentioned about static variables, just a single mentioning something like "the developer should not rely on static variable in distributed environment", I think this one is obvious.
Thus I would expect default JVM behavior, which is "Static is shared within a signle JVM" .

[Jerson Chua]

Please clarify this to me.
What should be the answer to this question? I think it should be D.

[chinna ram]

Does sun gave any eplanation for the answer it gave? if yes what is the explantation.
Thanks
Chinna

[Anthony Villanueva]

It should be D. If you implement SingleThreadModel, the container may create multiple servlet instances, in which case a static variable will NOT be thread-safe unless you explicitly make it so with custom code.