Servlet Thread Models

Before we look into using some of the functions we've seen as part of the Servlet API, we have to look at the threading model available for servlet developers. As mentioned earlier in the chapter, a servlet that implements the HttpServlet or the Servlet interface is capable of handling concurrent requests at the same time. A single servlet instance that's created either by the first request or at server startup time spawns multiple threads to handle all these requests through the doGet() or the doPost() method, based on the request type. In this programming model, the programmer should take care to handle all the shared data in the request processing method via service(), doGet(), and so forth. This is done by using synchronized blocks and methods. If the programmer forgets to synchronize resources, the system can be left in an invalid state.

The programmer can override this default behavior of the servlet if the servlet implements the SingleThreadModel interface. For example, if the SimpleServlet discussed earlier implements SingleThreadModel, the code snippet looks like the following:

public class SimpleServlet extends HttpServlet implements SingleThreadModel
{
           // Servlet Code
}

In this model, according to the Sun specification, Web containers must take care of synchronizing the requests to the servlet instance. Because the container processes one request for the servlet loaded in memory, there is no question of sharing data.

Because synchronous access to such a servlet will substantially increase latency, especially if the servlet is used frequently, Web containers have devised ways to make this more efficient by concepts such as servlet pooling and so on. The methodology adopted to synchronize the requests depends on the implementation of the Web container. Some containers queue the requests in the server or, in certain cases, create multiple instances of the SingleThreadModel servlet to process simultaneous requests and every request being processed in a single thread.

WebLogic Server provides a servlet-pooling feature for making the SingleThreadModel more efficient. WebLogic Server creates an instance pool containing multiple instances of the SingleThreadModel servlet based on a configuration parameter. Figure 14.4 shows how to configure the Servlet Pool Size parameter.

The default value of this parameter is set to 5 and the pool is created when the first request comes to the servlet. WebLogic Server increments the instances in the pool based on the requests in the server queue.

One important consideration for developers of single-threaded model servlets in WebLogic Server is that you must take care of synchronizing access to shared resources such as database resources in the servlet methods—service(), doGet(), and doPost()—because multiple instances of the same servlet exist that are accessing the shared resources at the same time. The performance impact of synchronization should be considered when designing such a servlet. Because the SingleThreadModel offers sluggish performance, or the false impression of thread safety when using multiple instances, it should be discouraged in favor of synchronization blocks/methods.