JSP State Management

The Stateless Nature of HTTP

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.

.

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.

Why Track Client Identity and State?

    

The fact that HTTP is a "stateless protocol" has important consequences when we communicate with web applications via HTTP. In the introduction to this chapter, we discussed one scenario where we need to maintain state, the shopping cart application. Consider another scenario:

·        Typical online banking can involve one or more banking transactions. Most such transactions may spawn across several pages. In order to maintain the transactions, we need a mechanism to uniquely identify the user, to track the activity of the user within the site, and to relate the transactions to the account/transaction data stored in backend systems.

In both scenarios we mentioned above there are two important activities:

·         Tracking the identity of a user

As the user makes multiple requests to the same web application over a period of time, we need a mechanism that links these requests together. Effectively, this means that we need to associate each request with a client identifier, so that we can identify requests from the same user.

·         Maintaining user state

Since there is often data associated with each request, we will need a way to associate the request data with the user that made the request, and a way to preserve that data across requests.

The ability to associate a request with the client that made the request is known as maintaining a session. However, the obvious next question to ask is: what mechanisms can we use to maintain sessions?

How do we Maintain Sessions?

we saw that there are many situations in which we need to keep track of state. Essentially this meant that we must preserve the identity of the client and the data associated with the client across requests. Since HTTP is a stateless protocol, just how do web applications manage to keep track of users?

In the following sections, we will discuss various mechanisms that we can use to maintain state across requests. We will consider the following approaches:

• URL rewriting
• Cookies
• Hidden-form fields

These techniques are used to maintain sessions in not only Java-based applications, but web applications written in many other languages too. Out of these three, the most common approach is to use cookies.

The Java Servlet API provides a way of maintaining sessions via two of these techniques: cookies and URL rewriting. We will examine the session-related interfaces and classes from the API later too.

Session handling is based on a simple idea that two entities can identify each other by exchanging some token (a unique identifier that both entities recognize) with each message. For instance, if your name is "Bob", and the name "Bob" is unique as far as the server is concerned, you may send the token "Bob" with each request to the server to uniquely identify you. Of course, this token need not be your name; it can be any piece of data that uniquely identifies you. The idea behind all session handling techniques is the same: they all rely on exchanging a server-generated unique ID with each request.

The HttpSession interface provides core session-management functionality. This interface abstracts a session. The container creates a session when a client first visits a server. Conceptually an HttpSession object is an object that lives for the duration of a client session, and is associated with the request objects.

J2EE web containers use three mechanisms to establish sessions:

• Cookies
   
  By default, most containers rely on cookies to establish sessions.
  
  
• URL rewriting
   
  Web containers support URL rewriting to accommodate clients that do not accept or support cookies. However, in order for web applications to work correctly with URL rewriting, we need to take an extra coding step by calling the encodeURL() method with each URL, and using the return value in the content (instead of the original URL).
  
  
• SSL based sessions
   
  The Secure Socket Layer (SSL) protocol is used for secure HTTP (HTTPS).
  
  

  The session handling interfaces of this API allow you to not only track users across requests by establishing sessions, but they also allow you to maintain state for each session. We saw that the default mechanism used by the API to maintain sessions was to use cookies, but we noted that it is capable of using the URL rewriting mechanism instead, in the case where cookie creation was not permitted by the client.

  
  

  
  

  While session handling features are useful for storing information in memory, there are associated risks with doing so - particularly in production environments. These risks include loss of performance and reliability. Both of these issues can be addressed by carefully considering which attributes we should add to a session, and for how long we need to keep them in the session.