File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes About SingleThreadModel Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "About SingleThreadModel" Watch "About SingleThreadModel" New topic
Author

About SingleThreadModel

Zhiyong Sun
Greenhorn

Joined: Nov 24, 2002
Posts: 4
In the Mock Test from JWeb+, there is a question like this:
Which of the following statements are correct? and the answer given is "Implementing SingleThreadModel ensures your servlet is thread safe, while I think the other answer "Servlets that not implement SingleThreadModel are not thread safe." is correct.
I wonder whether I am right.
Also in another Mock Test from Javaranch like this
"If you have a class that is accessed by a Servlet implementing the
SingleThreadedModel, no additional controls for synchronization are needed
to protect resources and are considered threadsafe."
The answer is false, which I think is correct. Implementing SingleThreadModle does not 100 percent ensures a servlet thread safe as we know.
Can anybody confirm my doubt for the first qusetion?
g madhava
Ranch Hand

Joined: Sep 14, 2001
Posts: 85
I don't have the question in front of me,but I assume that it would be something to pick up the best choice/option
Implementing the SingleThreadModel ensures that the thread access to the service() method is synchronized.
Servlets that not implement SingleThreadModel are not thread safe. This can be easily be a matter of fact when you consider writing code which is aware of the Synchonization probelms
1) like Synchronization blocks in the doGet()/doPost()/service() methods
2) use of local variables.
etc...
"Implementing SingleThreadModel ensures your servlet is thread safe" to the access of the service method
HTH.
B Mampilli
Ranch Hand

Joined: Aug 05, 2002
Posts: 61
"Servlets that not implement SingleThreadModel are not thread safe." is correct.
*****************************

It is not neccesary.... It is possible that Servlets are not implementinmg the SingleThreadModel and yet they are threadsafe...
***************************
"Implementing SingleThreadModel ensures your servlet is thread safe"
This would be the correct depending on the options that you have to select from...
remember that in the exam you have to do selection by elimination...
implementing the STM makes the servlet Threadsafe WRT execution of the service method ...
regards,
Bonson
SCJP
SCWCD
Dhanesh Kothari
Greenhorn

Joined: Nov 06, 2002
Posts: 28
If your servlet uses Static variables, context attributes, simply implementing STM does not guarantee Thread Safety.
So there is no way that thread safety can be ensured, with or without STM.


SCJP, SCWCD, SCBCD, IBM OOAD-UML, SCEA
Sudd Ghosh
Ranch Hand

Joined: Oct 23, 2002
Posts: 187
I think static variables have nothing to do with synchronization. Implementing STM gurantees to synchronize the threads accessing the service method. The access to any static variable from within this method (ONLY) is still synchronized. Now static variables are like globals, so if someone intends to modify that from some other un-synchronized method, that is always possible. That has nothing to do with STM and that is true for multithreaded programming in general.
In such cases, if it's a static reference, all other methods should be synchronized on this reference to eliminate the possibility of concurrently modifying the static reference from different methods.
Pls. correct me if I'm wrong.
Thanks, Sudd


SCJP 1.4, SCWCD, SCBCD 1.3
Debashish Chakrabarty
Ranch Hand

Joined: May 14, 2002
Posts: 230

Hi Ranchers,
Implementing the SingleThreadModel inerface makes a Servlet Threadsafe. OK! Then how come the following directive makes a JSP threadsafe and lets it implement SingleThreadModel interface?

Isn't it confusing? I mean, shouldn't that be following?

Hope I did not say anything stupid here! :roll:
[ December 09, 2002: Message edited by: Debashish Chakrabarty ]

Debashish
SCJP2, SCWCD 1.4, PMP, ITIL Foundation
friso jonge
Ranch Hand

Joined: Aug 06, 2002
Posts: 41
hmmm, i just read the following in this discussion thread.
Implementing the SingleThreadModel inerface makes a Servlet Threadsafe
This is not true !!! STM helps towards thread safety and assures you that only one thread at the time accesses this servlet instances' service method. However containers can create more than one instance of each servlet, or create a pool of instances. If you have a pool of instances, then all the instances share the same static variables. This makes that static variable not threadsafe.
Therefore implementing the STM alone does not make the servlet threadsafe. You have to synchronize access to your statics.
i would like to see an answer to the jsp-threadsafe remark above my reaction.
cheers,
friso
Sudd Ghosh
Ranch Hand

Joined: Oct 23, 2002
Posts: 187
Regarding the question on "isThreadsafe" attribute, the following is the explanation from Marty Hall's book.
The default is <%@ page isThreadSafe="true" %> which assumes that the servlet is thread safe, ie, the servlet synchronizes access to data in its fields (typically using the "synchronized" keyword in the JSP code generating the servlet). This is the normal servlet behaviour: multiple simultaneous requests are dispathed to multiple threads concurrently accessing the same servlet instance.
You use <%@ page isThreadSafe="false" %> to indicate that your code is NOT thread safe ("synchronized" NOT used inside the JSP code) and thus that the resulting servlet should implement the STM.
Regarding the other question "whether STM guarantees anything or not", again this is EXACTLY what Marty Hall says:
"If a servlet implements the STM interface, the system GUARANTEES that there will not be simultaneous access to the same servlet instance. The system can satisfy this guarantee either by queuing up all the requests and by passing them to the same servlet instance or by creating a pool of instances, each of which HANDLES A SINGLE REQUEST AT A TIME".
Thanks, Sudd
Sudd Ghosh
Ranch Hand

Joined: Oct 23, 2002
Posts: 187
Regarding Friso's comment:
"You have to synchronize access to your statics."
I am seconding this now.
I went thru' another para in Marty's book which EXACTLY says the following: "With STM, you don't have to worry about simultaneous access to regular fields (instance variables) of the servlet. You DO, however, still have to synchronize access to class variables (static fields) or shared data stored outside the servlet."
I hope this helps. Thanks.
Debashish Chakrabarty
Ranch Hand

Joined: May 14, 2002
Posts: 230

I am entirely confused guys! And please my question does not discuss the demerits of using SingleThreadModel interface
First Question: What is the default servlet beahaviour? I always thought it's *not* threadsafe, because of the concurrent thread accesses. So Default for a Servlet in JSP terms would be isThreadSafe=false, right?
Second Question: How come the default JSP behaviour isThreadSafe=true mean the same yet appear the exact opposite?
Third: If my Servlet implements SingleThreadModel we assume it has become ThreadSafe (OK,OK...we know that's not *entirely* threadsafe and that implementing this interface has performance issues), how come isThreadSafe=false attribute signal to the JSP container to implement SingleThreadModel (or synchronize access, whatever).
I think you guys must have got the point. If a layman reads the attribute and the explanation then the JSP and Servlet thread-safety issues have been explained conversely and that confused me.
Now for some stuff I got to backup my argument from here.

"By default this is set true, signaling to the JSP engine that that multiple client requests can be dealt with at once. It's the JSP author's job to synchronize shared state, so that the page really is thread safe. If isThreadSafe is set to false, the single thread model will be used, controlling client access to the page. This doesn't let you off the hook, however, as servers may, at their discretion, have multiple instances of the page running to deal with the client request load. And there's no guarantee that consecutive requests from the same client will be directed to the same instance of JSP page. Any resources or state that are shared between page requests must therefore be synchronized."
Thanks
k space
Ranch Hand

Joined: Jun 25, 2002
Posts: 104
Thread-safe in here means service (or _jspService) method can safely handle multiple requests from different threads at the same time.
By default Web container assumes that all servlets and JSPs are thread-safe. As a servlet or JSP author, you need to ensure your servlet or JSP can achieve that. If not, you have to tell the Web container by implementing SingleThreadModel or setting isThreadSafe="false". Web container may satisfy the requirement by serializing requests on an instance, or by maintaining a pool of instances.
If your servlet or JSP is badly written (e.g. accessing shared objects are not properly synchronized), SingleThreadModel or isThreadSafe="false" won't help you much.
Hope it helps


SCEA | SCBCD | SCWCD | SCJP - The kSpace
Sudd Ghosh
Ranch Hand

Joined: Oct 23, 2002
Posts: 187
Thanks for the nice explanation from Mr. Wong.
Sudd
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: About SingleThreadModel