This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
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?
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.
"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
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
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
Joined: Oct 23, 2002
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
Joined: Oct 23, 2002
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.
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
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