what is SingleThreadModel in java. How to implement in JSP

     Do you want your servlet  to be thread-safe, and you want to limit the overhead of synchronization?.  Then you may consider the the option using SingleThreadModel but it is now deprecated because of certain limitations and poor performance problems. This tutorial covers the technical aspects of SingleThreadModel ,  advantages and  disadvantages of using of the SingleThreadModel. Also covers that why programmers are discouraged from using this interface?.   Let us see first what happens when a servlet is not  implemented with this  interface.  The container creates only single instance of a servlet and  sends multiple service requests with different threads to the instance. This leads to thread unsafe of the servlet due to  instance variables declared in it are shared between multiple threads simultaneously.  Now how to make the it thread safe?    

To make the servelet thread-safe , the implementation of the service() method should be thread-safe.   There are many ways to make the servlet thread safe.  One ways  is to implement the it by  the marker  interface called SingleThreadModel. 

       Now let us see  what happens when a servlet is implemented with this marker interface that has no methods. First of all it tells the container that the servlet is not thread safe. Now the container  ensures that servlets handle only one request at a time i.e. “no two threads will execute concurrently in the  service method”.  SingleThreadModel can be implemented  as given  below.

 where SingleThreadServlet is the servlet name.
SingleThreadModel can be implemented for a JSP by including the page directive in the JSP as given below
                                               <%@ page isThreadSafe=”false” %>
               The servlet container may follow  one of the below approches to make the servlet thread safe when you  implement  it  by  the interface SingleThreadModel.
       Ist Approach :  Maintains  single instance of the servlet  and allows   serializing access to  that instance. 
     IInd Approach :  Maintains a pool of servlet instances and  for  each new request ,  the container allocates a free servlet instance from the pool. 
                     
                              As per the servlet specification version 2.3,
  The better approch will be to maintain a optimized  number of instances in the pool and serializing requests if the number of requests exceeds the  number of instances in the pool. 
Reasons to consider  using SingleThreadModel in Servlets (Advantages): 
                1.  Makes the servlet instance thread safe by reducing  synchronization and managing reusable objects :   When the servlet is  implemented by the SingleThreadModel ,  the servlet engine  maintains a pool of serially reusable servlet instances, where each  instance can be used by only one thread at a time. Therefore, any servlet which implements the SingleThreadModel is considered to be thread-safe, and no synchronization is required when accessing any  instance variables or objects.   When the servlet follows this approach (IInd approach) , performance is significanly improved. 
                 2. Expensive resources such as database connections  required for  your application  can be serially reused and  no need to create your own pool to manage them. As SingleThreadModel, is another way to protect updateable  instance variables,  we can declare one “connection” instance variable per  servlet  to get the database thread-safe connection .  As  pool of servlet instances are maintained when using  SingleThreadModel,   a servlet can handle concurrent requests, that means  two or more threads can safely perform database operations simultaneously which is almost similar to using connection pool.
Reasons to avoid using SingleThreadModel in Servlets (Disadvantages): 
                 1.   The sad part using this model is that it does not solve all thread safety issues.  As per the servlet specification version 2.3 ,
      The SingleThreadModel interface guarantees that only one thread at a time will execute the servlet instance’s service method. That means the instance variables declared in it are said to be thread safe. No need to worry about local variables (method variables) as they are already thread safe.  Let us see some of the thread saftey issues which may arise even if you implement SingleThreadModel. This can be solved only with careful synchronization.
        a)  Objects that can be accessible to more than one servlet instance at a time, such as attributes  of  HttpSession object and static variables may not be thread safe. i.e   Attributes and objects stored in the session   and static variables can  be accessed by multiple requests on multiple threads at the same time, even when the servelet is implemented by SingleThreadModel.  But how multiple threads (two or more threads) can access the same session at the same time?  It is possible to make  two or more  ajax calls  at the same time which may access and  modify the same session attribute. 

          b) Suppose your servlet requires  access to a external shared resource (such as File access), the servlet needs to synchronize against the resource even if you implement it  with SingleThreadModel. As these resources are shared between multiple threads,  there is no difference if two threads are on the same  instance or on different  instances of the servlet; in both cases  two threads are trying to access the same resource which requires proper synchronization.
2.  If the servlet container  follows the first approch (Ist Approach –  Serializing requests to the same instance of the servlet)   to make the servlet thread safe when you  implement the servlet  by  the interface SingleThreadModel , it leads to  significant impact on performance.  The servlet container’s ability to process concurrent requests will be affected heavily due to serialization. 
3.  If the servlet container  follows the second approch (IInd Approach : to maintain a pool of servlet instances  and  each new request is  allocated a free servlet instance from the pool) , the container has to create more objects and obviously requires more memory usage. This causes a great amount of system overhead.   
Why the SingleThreadModel is deprecated ?
                            Developers may  think  that  servlet which implements the SingleThreadModel interface and JSP that uses the directive isThreadSafe=”false” are completly thread-safe. But  it does not solve all the thread safety issues as we have seen in the above section.  Also it leads to poor performance.   That is why this interface is deprecated  in Servlet API version 2.4 with out any  replacement.  
Final conclusion:
           It is advised that a developer may concentrate on writing a thread-safe multi-threaded servlet , instead of using SingleThreadModel.  They can  take other ways to resolve those issues such as avoiding the usage of an instance variable or synchronizing the block of the code accessing the shared  resources  instead of implementing this interface atleast for servlets with high-traffic. 
              As far as JSP is concerned , it is advised not to use the directive  isThreadSafe=”false” especially when you will be using a JSP as a front end to the servlets. 

You may also like

Leave a Reply