aspose file tools*
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes SingleThreadModel question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "SingleThreadModel question" Watch "SingleThreadModel question" New topic
Author

SingleThreadModel question

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
In the sample Web Component Developer test that Sun sells for $50, the answer to a similar question to the one below is given as [A]. (I�ve modified the question superficially to hopefully avoid any copyright infringements).
Shouldn�t the answer be D? The Servlet 2.2 API documentation for the SingleThreadModel interface states, "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".
-------------
Question:
Given:
1. public class TestServlet extends HttpServlet implements SingleThreadModel {
2. private static int num = 5;
3. public void doGet(HttpServletRequest req, HttpServletResponse resp) {
4. // do nothing;
5. }
6. }
Which statement is true?
A) Variables num and req are both thread safe
B) Variables num and req are both not thread safe
C) Variable num is thread safe, while variable req is not thread safe
D) Variable num is not thread safe, while variable req is thread safe
Shamaila Mahmood
Greenhorn

Joined: Aug 28, 2001
Posts: 16
The question is a bit tricky, no doubt answer appears to be D. Here is an attempt to justify the sun's answer. As the variable num is static it is not associated to a particular instance but being a private member it cannot be accessed using Class.method() syntax. The only way of changing the value of this variable is to set it within the class. So here is a variable that can only be changed by
1)class's methods
2)static initializer
3)instance initializer
But in the case of this question none of above is changing value of the variable num. That's what make it thread safe. I drew this conclusion from the comment in the doGet... //do nothing
Just a guess
Khanh Nguyen
Greenhorn

Joined: Sep 06, 2001
Posts: 12
Shamaila - I got two questions for clarification purposes. So if num was not a private variable then num would not be thread safe. Or if within doGet, num is set to a different value then num would not be threadsafe also.
Just making sure I understood your explanation. This is a very tricky question.
Shamaila Mahmood
Greenhorn

Joined: Aug 28, 2001
Posts: 16
Originally posted by Khanh Nguyen:
Shamaila - I got two questions for clarification purposes. So if num was not a private variable then num would not be thread safe. Or if within doGet, num is set to a different value then num would not be threadsafe also. (

(first question) If num was not a private variable:
Actually static variable are not thread safe as all the instances of this class can access/modify them either by onjectName.staticVariableName or by ServletClassName.staticVariableName,
but as num is a private variable so you can not access it in either of these two ways.
But any method of the servlet class can modify its value. so all the instances of servlet class can modify the same static variable even if it is private. That's why private static variables can not be considered as thread safe.
(second question)if within doGet, num is set to a different value then num would not be threadsafe also:
In all the cases where we know that no method of the servlet class modify the value of a variable(static or instance) then we can say that this variable is theard safe. So thread safety of a variable depends upon the code. means depending on the imlementation of the servlet you can say that a particualr variable is thread safe even if the variable is an instance variable.
Tim Duncan
Ranch Hand

Joined: Aug 20, 2001
Posts: 150
Originally posted by Shamaila Mahmood:
Here is an attempt to justify the sun's answer.

All praise for a very creative answer, but if that really is Sun's intention (and not just a mistake), then I'd say it is a trick question.
Carl Trusiak
Sheriff

Joined: Jun 13, 2000
Posts: 3340
I think Sun is wording the question improperly. In this example, (IMHO) num is not ThreadSafe. Implementing the SingleThreadedModel doesn't change this. However, since SingleThreadedModel ensure that only one thread can be in the service method at a time, Operations can safely occur on num in the service method without be impacted by another thread (Which is what Thread Safety is all about).
So, as I see it Sun is actually asking "Which of these variable can be safely manipulated in the service method of a servlet that implements the SingleThreadedModel?

I Hope This Helps
Carl Trusiak, SCJP2, SCWCD
BJ Grau
Ranch Hand

Joined: Jul 10, 2001
Posts: 234
Carl - Suppose the container is enforcing the thread safety through instance pooling (and not serialization of requests). So now we can have multiple instances of the servlet running, and we know that only one thread is running through the service method of each instance. Now we have multiple threads (each running through a separate instance) with access to the same shared resource num. It seems like in this case we could have problems with num. What am I missing here?
Tim Duncan
Ranch Hand

Joined: Aug 20, 2001
Posts: 150
Isn't the position complicated by the possibility of pooling?
I thought (and I'm not particularly confident here) that the SingleThreadedModel ensures that a servlet instance can only be accessed by a single thread at one time. However some servers provide a pool of servlet instances to handle requests.
If "num" was a simple instance variable then it would be thread-safe under the SingleThreadedModel, but since it is static it can be accessed by other instances of the servlet, and hence by other threads.
Have I got this right?

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
I'm now certain that Sun either worded this question improperly or they have a typo in their answer. They had a similar question in the SCWCD exam I took yesterday, and there, I regarded the static private variable as non-thread-safe (eventhough it was not being referenced by any method or initializer code), and the answer was marked correct.
BJ and Tim are both correct. The static variable num is not thread safe. This is true with or without SingleThreadModel.
(a) When not implementing SingleThreadModel, there is the risk that multiple service requests or multiple named instances of the servlet (registered via <servlet-name> ) can modify the static variable simultaneously.
(b) When implementing SingleThreadModel, there is still the risk that num is modified by multiple pool instances or multiple named instances simultaneously.
But regardless, it's just not a good idea to use static variables to share state. Not only is it not thread-safe, but if you ever want to make your web application distributable in the future, you'll have to eliminate such code, since a servlet in this configuration will have different instances loaded on different JVM's and hence by different class loaders. So, they will not be able to see each other's class variables.

[This message has been edited by Miftah Khan (edited September 20, 2001).]
BJ Grau
Ranch Hand

Joined: Jul 10, 2001
Posts: 234
Great!! Congrats on passing the exam, and thanks for confirming my thoughts. I was in dire need of somebody to come in here and set me straight. SingleThreadModel has been a problem for me due to hearing conflicting ideas from folks at work and reading conflicting information about it. Now I've got it. Thanks.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: SingleThreadModel question