Hi All, I want to create a Thread safe JSP page. It is possible in Servlet by implementing SingleThreadModel interface but I don't know how to do it in JSP page.
You don't.
JSP is basically a single method in a servlet. As you may know already, methods are thread safe, the the sense, that two threads invoking the same method of the same object at the same time, will execute each one in its own stack.
So, you don't really need to make a thread safe JSP, because, it is trade safe already.
If you declare a variable a
in a JSP, there is no way, another request sees that variable.
What you must be aware of, is, objects put into the session, or the context may be accessed by multiple threads at the same time, or pretty much not thread safe code. Then what you must synchronize or take care of, are those objects!, and not the JSP page it self.
Talking about thread-safety with JSP is wrong - JSP is a view technology and it only displays results - it doesn't do any processing. (it can do processing, but it must not)
Thread-safety with servlets is achieved by having no private fields in the servlet - the servlet instance is one for the whole container and each request is a new thread invoking the service(..)
method.
You should specify exactly what you mean by "thread-safety" in your case - i.e. what do you expect to fail.
By not having any state information in your JSP page. (No instance variables, that can change accross different requests). If you do not have any state in your JSP or servlet, they are threadsafe
First the short answer <%@page isThreadSafe="false" %>
The longer answer is don't do that.
You need to be very clear about your objective here. You haven't made a servlet truly thread-safe by using a SingleThreadModel, rather you have set things up so that only one thread at a time can get into your servlet. Presumbly you would be doing that exactly because the Servlet code is not thread safe, that is if more than one thread were to get at the code bad things would happen.
This implies to me that you have something like this in the servlet code:
doGet(/*etc/*){
// ... stuff
someExistingUnsafeClass.doSomething();
// .. more stuff
}
After all, your serlvet code itself cannot be thread-unsafe, surely? You would fix it, right? So it must be some legacy code that's thread-unsafe?
If this is the scenario, with your JSP needing to use that existing legacy code, somewhere in your JSP you have a call that unsafe stuff:
<%
someExistingUnsafeClass.doSomething();
%>
So you just need to protect this unsafe call:
<%
synchronized(this){
someExistingUnsafeClass.doSomething();
};
%>
Allowing the bulk of your JSP to run properly threaded will perform much better.
I should also say, that if you structure your application as MVC then all thread-unsafe code is called from the controller and the view (the JSP) never needs to be unsafe.
Theoretically, JSP pages can be indicated as threadsafe via the isThreadSafe
page directive attribute. Setting a value of false, will get the container to synchronize access to page level objects (and not to session and application scoped objects or objects of any other variety). Obviously, it is still the responsibility of the developer to ensure that synchronous access to thread unsafe regions of code.
Morevoer, the SingleThreadModel interface has also been deprecated in the Servlet Specification release 2.4. The SingleThreadModel interface is used to implement the supposed thread safety in JSPs as well - generated servlet classes will implement the SingleThreadModel for JSPs that use the threadsafe attribute. The specification itself outlines why the interface is deprecated:
SRV.2.2.1 Note About The Single Thread Model
The use of the SingleThreadModel interface guarantees that only one thread at a time will execute in a given servlet instance’s service method. It is important to note that this guarantee only applies to each servlet instance, since the container may choose to pool such objects. Objects that are accessible to more than one servlet instance at a time, such as instances of HttpSession, may be available at any particular time to multiple servlets, including those that implement SingleThreadModel.
It is recommended that a developer take other means to resolve those issues instead of implementing this interface, such as avoiding the usage of an instance variable or synchronizing the block of the code accessing those resources. The SingleThreadModel Interface is deprecated in this version of the specification.
In JSP, just use variables in scriplets and you can be confident that they are thread safe because they will be translated into local variable in service()
.