Session Tracking

The Java^TM Tutorial

Start of Tutorial > Start of Trail > Start of Lesson

Search
Feedback Form

Trail: Servlets
Lesson: Saving Client State

Session Tracking

Session tracking is a mechanism that servlets use to maintain state about a series of requests from the same user (that is, requests originating from the same browser) across some period of time.
Sessions are shared among the servlets accessed by a client. This is convenient for applications made up of multiple servlets. For example, Duke's Bookstore uses session tracking to keep track of the books being ordered by a user. All the servlets in the example have access to the user's session.
To use session tracking,

Get a session (an HttpSession object) for a user.

Store or get data from the HttpSession object.

Invalidate the session (optional).

Obtaining a Session

The getSession method of the HttpServletRequest object returns a user's session. When you call the method with its create argument as true, the implementation creates a session if necessary.

To properly maintain the session, you must call getSession before any output is written to the response. (If you respond using a Writer, then you must call getSession before accessing the Writer, not just before sending any response data.)

The Duke's Bookstore example uses session tracking to keep track of the books in the user's shopping cart. Here is an example of the CatalogServlet getting a session for a user:

    public class CatalogServlet extends HttpServlet { 

        public void doGet (HttpServletRequest request,
                           HttpServletResponse response)
    	throws ServletException, IOException
        {
            // Get the user's session and shopping cart
	    HttpSession session = request.getSession(true);
            ...
	    out = response.getWriter();
            ...
        }
    }

Storing and Getting Data from a Session

The HttpSession interface provides methods that store and return:
:

Standard session properties, such as a session identifier
Application data, which is stored as a name-value pair, where the name is a String and the value is an object in the Java programming language. (This is like java.util.Dictionary.) Because multiple servlets have access to a user's session, you should adopt a naming convention for organizing the names associated with application data. This avoids servlets accidentally overwriting each other's values in the session. One such convention is servletname.name where servletname is the full name of the servlet, including its packages. For example, com.acme.WidgetServlet.state is a cookie with the servletname com.acme.WidgetServlet and the name state.

The Duke's Bookstore example uses session tracking to keep track of the books in the user's shopping cart. Here is an example of the CatalogServlet getting a user's session identifier, and getting and setting the application data associated with the user's session:

    public class CatalogServlet extends HttpServlet { 

        public void doGet (HttpServletRequest request,
                           HttpServletResponse response)
    	throws ServletException, IOException
        {
            // Get the user's session and shopping cart
	    HttpSession session = request.getSession(true);
	    ShoppingCart cart =
                (ShoppingCart)session.getValue(session.getId());

        // If the user has no cart, create a new one
        if (cart == null) {
            cart = new ShoppingCart();
            session.putValue(session.getId(), cart);
        }
            ...
        }
    }

Because an object can be associated with a session, the Duke's Bookstore example keeps track of the books that a user has ordered within an object. The object is type ShoppingCart and each book that a user orders is stored in the shopping cart as a ShoppingCartItem object. For example, the following comes from further down in the doGet method of the CatalogServlet:

    public void doGet (HttpServletRequest request,
                       HttpServletResponse response)
	throws ServletException, IOException
    {
	HttpSession session = request.getSession(true);
	ShoppingCart cart = (ShoppingCart)session.getValue(session.getId());
        ...
        // Check for pending adds to the shopping cart
        String bookId = request.getParameter("Buy");

        //If the user wants to add a book, add it and print the result
        String bookToAdd = request.getParameter("Buy");
        if (bookToAdd != null) {
            BookDetails book = database.getBookDetails(bookToAdd);

            cart.add(bookToAdd, book);
            out.println("<p><h3>" + ...);
        }
    }

Finally, note that a session can be designated as new. A new session causes the isNew method of the HttpSession class to return true, indicating that, for example, the client does not yet know about the session. A new session has no associated data.

You must deal with situations involving new sessions. In the Duke's Bookstore example above, if the user has no shopping cart (the only data associated with a session), the servlet creates a new one. Alternatively, if you need information from the user to start a session (such as a user-name), you might want to redirect the user to an "starting page" where you collect the necessary information.

Invalidating the Session

A user's session can be invalidated manually or, depending on where the servlet is running, automatically. (For example, the Java Web Server automatically invalidates a session when there have been no page requests in some period of time, 30 minutes by default.) To invalidate a session means to remove the HttpSession object and its values from the system.

To manually invalidate a session, use the session's invalidate method. Some applications have a natural point at which to invalidate the session. The Duke's Bookstore example invalidates a user's session after the user has bought the books. This happens in the ReceiptServlet:

    public class ReceiptServlet extends HttpServlet { 

        public void doPost(HttpServletRequest request,
                           HttpServletResponse response)
	    throws ServletException, IOException {

                ...
                scart = (ShoppingCart)session.getValue(session.getId());
                ...
                // Clear out shopping cart by invalidating the session
                session.invalidate();

                // set content type header before accessing the Writer
                response.setContentType("text/html");
                out = response.getWriter();
                ...
        }
    }

Handling All Browsers

By default, session tracking uses cookies to associate a session identifier with a user. To also support users that access a servlet with a browser that does not support cookies, or that is set up to reject cookies, you must use URL rewriting instead. (While some web servers support URL rewriting, the servletrunner utility that is part of the JSDK2.0 does not. For session tracking to work when a servlet is running within servletrunner, the user agent must support cookies.)

When you use URL rewriting you call methods that, when necessary, include the session ID in a link. You must call these methods for every link in the servlet response.

The method that associates a session ID with a URL is HttpServletResponse.encodeUrl in the JSDK2.0 and HttpServletResponse.encodeURL in the JSDK2.1. If you redirect the user to another page, the method to associate the session ID with the redirected URL is called HttpServletResponse.encodeRedirectUrl in the JSDK2.0 and HttpServletResponse.encodeRedirectURL in the JSDK2.1.

The URL encoding and encoding redirect methods decide whether the URL needs to be rewritten, and return the URL either changed or unchanged. (The rules for URLs and redirected URLS differ, but in general if the server detects that the browser supports cookies, then the URL is not rewritten.)

Note: This section shows code that is not a part of the Duke's Bookstore example for JSDK2.1. Duke's Bookstore could use code like that shown in this section if it used URL rewriting. Because URL rewriting is not a part of Duke's Bookstore, think of the examples in this section as pseudo-code.

If the Duke's Bookstore example used URL rewriting, it would, for example, have the following code in the CatalogServlet:

    public class CatalogServlet extends HttpServlet { 

        public void doGet (HttpServletRequest request,
                           HttpServletResponse response)
	    throws ServletException, IOException
        {
            // Get the user's session and shopping cart, the Writer, etc.
            ...
	    // then write the data of the response
            out.println("<html>" + ...);
            ...
            // Get the catalog and send it, nicely formatted
            BookDetails[] books = database.getBooksSortedByTitle();
            ...
            for(int i=0; i < numBooks; i++) {
                ...
                //Print out info on each book in its own two rows
                out.println("<tr>" + ...

                        "<a href=\"" +
                        response.encodeURL("/servlet/bookdetails?bookId=" +
                                           bookId) +
                        "\"> <strong>" + books[i].getTitle() +
                        "  </strong></a></td>" + ...

                        "<a href=\"" +
                        response.encodeURL("/servlet/catalog?Buy=" + bookId)
                        + "\">   Add to Cart  </a></td></tr>" +

            }
        }
    }

Notice that the CatalogServlet returns two links to the user for each book. One link offers details about the book and the other allows you to add the book to your shopping cart. Both URLs would be rewritten because, again, every link that the servlet returns to the user must be rewritten when URL rewriting is used.

If the user clicks on a link with a rewritten URL, the servlet recognizes and extracts the session ID. Then the getSession method uses the session ID to get the user's HttpSession object.

On the other hand, if the user's browser does not support cookies and the user clicks on an un-rewritten URL, the user's session is lost. The servlet contacted through that link creates a new session, but the new session does not have the data associated with the previous session. Once a servlet loses the session data, the data is lost for all servlets that share the session. You should consistently use URL rewriting if your servlet is to support clients that do not support or accept cookies.

Start of Tutorial > Start of Trail > Start of Lesson Search
Feedback Form