Sun�s ePractive exam includes the following question:
Your organization has developed a new
J2EE Invoicing system, and during load
testing the system runs slow, but CPU and memory utilization remain low. To save time they embedded all the business logic into the JSPs as scriptlets.
What could be a cause of the problem?
A. You need to scale your application horizontally
B. You need to scale your application vertically
C.
Servlet instances are getting locked for every request
D. You are dropping database connections
E. Your load balancer needs to be re-polarized
The answer they give is as follows (Reference - Servlet 2.4 spec)
Option C is correct because the default behavior for JSPs is for the service method to be synchronized in the resulting servlet
I�ve always been of the opinion that the default model for Servlets, including Servlets generated from JSPs, is a multithreaded one. This is borne out by the Servlet and
JSP specs. The JSP spec has the following to say about the isThreadSafe page attribute:
Note: The Servlet 2.4 specification deprecates SingleThreadModel, which is the most common mechanism for JSP containers to implement isThreadSafe. Page authors are advised against using isThreadSafe, as the generated Servlet may contain deprecated code.
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.
Am I missing something obvious here?
