|< Free Open Study >|| |
In Chapter 3 we noted that the HTTP is by far the most common protocol used to communicate with web applications.
Consider this communication process. The client sends an HTTP request to a web server. The server receives the request, applies necessary processing logic, creates a response, and sends it back to the client. This request-response process happens across a single network connection. At the end of the process the server closes the connection. In addition, any failure on the server side or any network failure could terminate the request. The client may also terminate the connection before receiving the response from the server. This means that, when the client sends another request, all the request-response cycle happens again, but a new network connection must be established.
Now, there is an optional feature in HTTP 1.1 called "keep-alive" which allows the client to use the same connection across multiple requests. However, browsers use this feature only when the server supports it, and only when the requests happen in rapid succession.
At this point, you may be asking, why do HTTP-based connections only exist for the length of a single request-response cycle? Web servers cater to a potentially large number of users. For a server, accepting a network connection means listening to incoming requests over a socket. This consumes operating system level resources including threads and memory. In order to be able to serve a large number of users, HTTP is designed to use new connections for every request; this means that connections are not held beyond the duration of a request and a response, which minimizes the waste of system resources.
Given this stateless nature of HTTP, basic servlet programming is also stateless. Consider the javax.servlet.Servlet interface or the abstract javax.servlet.http.HttpServlet class that we use to write our own servlets. Within a service method (such as doGet() or doPost()), each servlet extracts request parameters, processes some application logic, and then generates the response. After writing the response to the HTTP request, the servlet loses its attachment to the request. For all practical purposes, you may even consider that the servlet instance does not even exist. Since an instance may or may not exist beyond a single request, we cannot store any data in the instance variables of a servlet.
From the servlet developer's point-of-view, this statelessness is a constraint. However, from the server/container's point-of-view, it is required to offer better performance and scalability by not spawning a new servlet instance for each new HTTP request. We improve web container performance because we avoid object allocation for each new request, and scalability because the container will have more resources left to serve more requests.
|< Free Open Study >|| |