Overview of How Web Servers Work and the Role of Java Servlets

Many developers wonder how web containers or web servers such as Tomcat or JBoss process HTTP requests from around the world, what actions they perform behind the scenes, and what role the Java Servlet API (ServletContext, ServletRequest, ServletResponse, Session, etc.) plays. This article aims to answer those questions.

What are web servers, application servers, and web containers?

Historically, web servers originated to serve static pages and images via HTTP. Over time they added CGI, caching, security, and session management features. Application servers, originally built for transaction‑oriented middleware (e.g., Tuxedo, Encina), later incorporated HTTP capabilities, blurring the line between the two. Today the distinction is mostly historical, and many products combine both roles.

In the Java ecosystem, a web container is essentially a Servlet container. It manages the lifecycle of Servlets, maps URLs to specific Servlets, enforces access control, and provides other services needed to run web applications.

What is a Servlet and what does it do?

A Servlet is a server‑side component defined by the javax.servlet interface that generates dynamic content. It declares three core lifecycle methods— init(), service(), and destroy() —which the container calls at appropriate times. Class loaders lazily or eagerly load Servlet classes, each request runs in its own thread, and a single Servlet instance can serve many concurrent threads. When a Servlet is no longer needed, the JVM garbage‑collects it.

Two loading strategies are illustrated:

Lazy‑loaded Servlet

Pre‑loaded Servlet

What is ServletContext and who creates it?

When the Servlet container starts, it deploys all web applications, creating a ServletContext for each and storing it in memory. The container also processes the web.xml descriptor, instantiating defined Servlets, Filters, and Listeners. Upon shutdown, all these objects are destroyed. ServletContext provides methods for MIME type lookup, request forwarding, logging, and more, but it should not be used as a global shared variable across JVMs.

Where do ServletRequest and ServletResponse enter the lifecycle?

The container listens on a port (typically 80). When a client sends an HTTP request, the container creates HttpServletRequest and HttpServletResponse objects, passes them through matching Filters and the target Servlet, all within a single thread. After the response is committed, both objects are discarded.

How is Session managed? Do you know cookies?

On the first request that calls request.getSession(), the container creates an HttpSession, generates a unique long ID, and stores it in memory. It also sends a cookie named JSESSIONID containing that ID. Subsequent requests include the cookie, allowing the container to retrieve the associated session. Sessions expire after a configurable idle period (default 30 minutes) or when the browser is closed, at which point a new session and cookie are created.

New Session

How to ensure thread safety?

All requests share the same Servlet and Filter instances, which is efficient but requires careful coding. Instance variables must never hold request‑ or session‑scoped data, as they would be shared across threads and lead to race conditions. The following example demonstrates a non‑thread‑safe pattern and a correct one.

public class MyServlet extends HttpServlet {
    private Object thisIsNOTThreadSafe; // Don't do this

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        Object thisIsThreadSafe;

        thisIsNOTThreadSafe = request.getParameter("foo"); // BAD!! Shared among all requests!
        thisIsThreadSafe = request.getParameter("foo"); // OK, this is thread safe.
    }
}

All topics have been covered; stay tuned for more articles.

(Source: ImportNew)