| Session Management in JSP |
| |
| Synchronization Issues |
| |
| By default, the service method of the JSP page implementation class that services the client request is multithreaded. Thus, it is the responsibility of the JSP page author to ensure that access to shared state is effectively synchronized. There are a couple of different ways to ensure that the service methods are thread-safe. |
| |
| The easy approach is to include the JSP page directive: |
| <%@ page isThreadSafe="false" %> |
| |
| For example: |
| <jsp:include page="tutorial.jsp" flush="true"/> |
| |
| This causes the JSP page implementation class to implement the SingleThreadModel interface, resulting in the synchronization of the service method, and having multiple instances of the servlet to be loaded in memory. The concurrent client requests are then distributed evenly amongst these instances for processing in a round-robin fashion, as shown below: |
| |
 |
| |
| The downside of using this approach is that it is not scalable. If the wait queue grows due to a large number of concurrent requests overwhelming the processing ability of the servlet instances, then the client may suffer a significant delay in obtaining the response. |
| |
| A better approach is to explicitly synchronize access to shared objects (like those instances with application scope, for example) within the JSP page, using scriptlets: |
<%
synchronized (application)
{
SharedObject form = (SharedObject)
application.getAttribute("sharedObject");
foo.update(someValue);
application.setAttribute("sharedObject",form);
}
%> |
| |
| |
|
| |
| |