1. Local variables Yes, thread-safe
2. Instance variables Not thread-safe
   Since a single servlet instance may be handling multiple service requests at any given time.
3. Class variables Not thread-safe
   Since multiple servlets and /or service requests may try to access a class variable concurrently.
4. Request attributes Not thread-safe
   See the quote below.
5. Session attributes Not thread-safe
   Since sessions are scoped at the web application level, hence the same session object can be accessed concurrently by multiple servlets and their service requests
6. Context attributes Not thread-safe
   Since the same context object can be accessed concurrently by multiple servlets and their service requests

7.2 Identify correct statements about differences between the multi-threaded and single-threaded servlet models.

multi-thread model servlet:

• one servlet instance per registered name
• for each servlet request, the server spawns a separate thread which executes the servlet's service() method
• must synchronize access to instance variables

  single-thread model servlet:

• has a pool of servlet instances per registered name (depending on the server implementation, the pool size may be configurable or not, and may be as little as one.)
• guaranteed by server "that no two threads will execute concurrently in the servlet's service method"
• considered thread-safe and isn't required to synchronize access to instance variables
• does not prevent synchronization problems that result from servlets accessing shared resources such as static variables or objects outside the scope of the servlet (e.g. ServletContext, HttpSession)
• server might end up creating more instances than the system can handle, e.g. each instance might have its own db connection, hence in total there may be more db connections than the db server can handle.

7.3 Identify the interface used to declare that a servlet must use the single thread model.

interface javax.servlet.SingleThreadModel { // this is an empty "tag" interface }

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. Multithreading Issues
A servlet container may send concurrent requests through the service method of the servlet. To handle the requests the developer of the servlet must make adequate provisions for concurrent processing with multiple threads in the service method.
An alternative for the developer is to implement the SingleThreadModel interface which requires the container to guarantee that there is only one request thread at a time in the service method. A servlet container may satisfy this requirement by serializing requests on a servlet, or by maintaining a pool of servlet instances. If the servlet is part of a web application that has been marked as distributable, the container may maintain a pool of servlet instances in each VM that the application is distributed across.
For servlets not implementing the SingleThreadModel interface, if the service method (or methods such as doGet or doPost which are dispatched to the service method of the HttpServlet abstract class) has been defined with the synchronized keyword, the servlet container cannot use the instance pool approach, but must serialize requests through it. It is strongly recommended that developers not synchronize the service method (or methods dispatched to it) in these circumstances because of detrimental effects on performance.

Thread-safe issue for Request & Response
Implementations of the request and response objects are not guaranteed to be thread safe. This means that they should only be used within the scope of the request handling thread. References to the request and response objects must not be given to objects executing in other threads as the resulting behavior may be nondeterministic.
-- SRV. 2.3.3.3.

Note: Javacamp.org would like to thank reader Andrew Zhou who pointed out a mistake in the notes and it has been corrected.

The request and response object are not thread safe according to the Servlet Specification 2.3 version. Please refer SRV.2.3.3.3 for more specific information.

Return to top