The Java servlet API specifies a very lightweight framework for developing Web applications. Although servlet technology is just one of the building blocks in the J2EE architecture, developers often use servlets to build full-fledged Web applications. Today several vendors and organizations provide servers and containers that implement the servlet API. For an overview of the servlet programming model, and some of the advanced features of Java servlets, refer to Part 1 of this article (JDJ, Vol. 5, issue 2).
As a lightweight framework, the servlet API doesn't impose a very strict programming model. Specifically, the API specification leaves certain design decisions to the developers. The servlet specification also added and withdrew (deprecated) certain features over its evolution. Unfortunately, though such deprecation was necessary to bring robustness to the servlet model, such changes sometimes cultivated incorrect programming practices. In addition, container vendors follow different models for implementing the API specification. In such a scenario it's essential for servlet programmers to be careful while making assumptions regarding those aspects that aren't covered by the servlet specification.
In this article I'd like to conduct an analysis of some of the design practices that servlet developers often undertake while developing Web applications. I draw some of the inputs for this article from the archives of the Servlet Interest Mailing List. Note: Some of the practices may not affect small-scale Web applications. The focus of my article is on servlets for large-scale Web applications that are required to be portable and scalable. While discussing these practices, I assume the containers will provide advanced features such as clustering, failover, and more.
Explicit Servlet Instantiation
This is a novice practice. Experienced programmers would probably snub me for mentioning this because they never do it. Nonetheless, allow me to elaborate on why you shouldn't instantiate servlets explicitly.
In brief, the hosting servlet container creates servlet instances. Instances created explicitly by applications can't receive HTTP requests from clients.
A servlet container creates servlet instances in response to HTTP requests. As discussed in Part 1 of this article, the purpose of a container is to receive HTTP requests, construct or locate a servlet instance, construct the environment for the servlet instance (a ServletContext), construct the request and response objects (the HttpServletRequest and HttpServletResponse objects), and delegate the incoming request to the servlet instance.
The key point here is that it's the servlet container's responsibility (and prerogative) to create servlet instances and delegate requests. Both the threading model that the developer follows and the instantiation model implemented by servlet containers dictate how and when servlet instances are created.
If a servlet implements the SingleThreadModel interface, the servlet container delegates each concurrent request to a different servlet instance or serializes incoming requests so that a single instance handles all the incoming requests, one after the other. If your LoginServlet implements the SingleThreadModel interface and there are five concurrent requests to this servlet, there are two possibilities. The first is that the container will delegate these five requests to five different instances of the LoginServlet. Alternatively, each of these login requests will be handled in series by just one instance. Once all the requests are served, the container may hold the instance(s) in a pool and reuse them for future requests.
