1

I was asked this question in a technical test recently, and have been wondering what would be a good answer, in case it comes up again.

Basically, given a scenario in which several race conditions have been found in JSP (due to extensive usage of instance variables and scriptlet code), what would be a good way to resolve the concurrency issues arising, without rewriting the code?

I answered along the lines of: making use of Spring beans to access the instance variables, so as to avoid multiple objects being created while accessing variables (since Spring beans are singleton in design, by default). I am keen to hear other interpretations or answers though.

czolbe
  • 571
  • 5
  • 18
  • Maybe this is jsp specific - but I have never heard of Java beans being singletons by design?! – GhostCat Dec 25 '17 at 10:38
  • 2
    My answer would be "There would be no good way to resolve the concurrency issues arising, without rewriting the code". Your answer doesn't make much sense: 1. using java beans is rewriting the code; 2. java beans are not singletons; 3. using singletons don't solve concurrency issues. 4. If they did, there would be no concurrency issue in the JSP, since a JSP is a singleton – JB Nizet Dec 25 '17 at 10:39
  • @GhostCat: sorry I meant Spring beans! Have edited my question – czolbe Dec 25 '17 at 10:40

1 Answers1

0

When a JSP is requested for the first time or when the web app starts up, the servlet container will compile it into a class extending HttpServlet and use it during the web app's lifetime (source).

JSP have a Page Directive Attributes. You can check it in the specification

Specifically, there is a attribute that you can change on the page:

<%@ page isThreadSafe="false" %>

This attribute indicates the level of thread safety implemented in the page.

  • If false then the JSP container shall dispatch multiple outstanding client requests, one at a time, in the order they were received, to the page implementation for processing.
  • If true then the JSP container may choose to dispatch multiple outstanding client requests to the page simultaneously.

Page authors using true must ensure that they properly synchronize access to the shared state of the page. Default is true. Note that even if the isThreadSafe attribute is false the JSP page author must ensure that accesses to any shared objects are properly synchronized. The objects may be shared in either the ServletContext or the HttpSession.

So, if you set the isThreadSafe attribute to false (thus that the resulting servlet should implement the SingleThreadModel) and you make sure that your scriplet do not use objects that shared in either the ServletContext or the HttpSession, then it may be a good way to resolve the concurrency issues.

Sergey Chepurnov
  • 1,397
  • 14
  • 23
  • Note: `SingleThreadModel` has been deprecated since Servlet 2.4 and is being removed in Servlet 6.0. This removal makes JSP's `isThreadSafe` directive a no-op. – Joakim Erdfelt Sep 21 '21 at 14:24