Persistent sessions

HTTP Sessions

Before we can start examining HTTP sessions, we must first understand their purpose. When the HTTP protocol the transport mechanism of all World Wide Web transaction was first introduced, it was intended to be only a simple request/response protocol, and no state was required to be maintained between autonomous requests.

This was fine until the Web's popularity exploded. One of the biggest demands as the Web's popularity grew was the ability to maintain between requests a state that is specific to each client.

These and similar problems are described by our experienced java engineers. If you want to host your Tomcat here, check out our VPS Hosting

Several solutions to this problem are currently available: cookies, hidden form fields, and HTTP sessions. In this chapter, we focus on HTTP sessions, specifically as they relate to Java servlets.

The Servlet Implementation of HTTP Sessions The Java Servlet SDK implements HTTP sessions using an interface named, appropriately enough, javax.servlet.http.HttpSession. This interface must be implemented by the servlet container.

The class that implements this interface will use a unique identifier, the session ID, to look up a user's session information. This identifier is stored in the client's browser and is part of every HTTP request.

The HttpSession interface defines several methods for accessing a user's session information. This SessionServlet performs some basic, but very useful, session management.

Its first step is to get a reference to the HttpSession object using the following line code:

HttpSession session = request.getSession();

Once the servlet has a reference to the user's session, it prints some basic information about the session, including the unique ID representing this user's session, the creation time, and the last access time.

It does this in the following code snippet:

// Print the current Session's ID out.println("Session ID:" + " " + session.getId()); out.println("<br>"); // Print the current Session's Creation Time out.println("Session Created:" + " " + new Date(session.getCreationTime()) + "<br>"); // Print the current Session's Last Access Time out.println("Session Last Accessed" + " " + new Date(session.getLastAccessedTime()));

The next step is where the meat of the servlet exists. It begins by retrieving the request parameters name and value. If these parameters exist, it adds them to the user's HttpSession object using the setAttribute() method as follows:

if ( dataName != null && dataValue != null ) { // If the Parameter Values are not null // then add the name/value pair to the HttpSession session.setAttribute(dataName, dataValue); }

After the SessionServlet adds the new object to the session, if the parameters exist, it then gets a reference to a java.util.Enumeration that contains all of the names bound to objects in the HttpSession and prints them. This code is contained in this final snippet:

// Get all of the Attribute Names from the HttpSession while ( names.hasMoreElements() ) { String name = (String) names.nextElement(); // Get the Attribute Value with the matching name String value = session.getAttribute(name).toString(); // Print the name/value pair out.println(name + " = " + value + "<br>"); }

The final bit of functionality in the SessionServlet creates the form that submits new name/value pairs. You can just briefly look this code over, as it is relatively simple and does not warrant a detailed explanation.

To see this servlet in action, build the class file and move it into the <TOMCAT_HOME>/webapps/thetest/WEB-INF/classes/chapter7/ directory. Next, open your browser to the following URL:

http://localhost:8080/thetest/servlet/chapter7.SessionServlet

At this point, no session attributes should be listed.