Developing Java Enterprise Applications:Programming Servlets

Table of Contents

Once you get the session object, you can use it to access the session data as a set of named values. There are also methods for getting the session’s id and information about its creation. All of these are listed in Table 7.14.

When a session is first created, it is considered new. The session remains new until the client “knows” about the session. There are two ways the client learns about the session. First, the session-tracking mechanism tries to use cookies to tell the client about the session id. If the browser supports and accepts the cookie, this mechanism is transparent to the programmer. The other way to tell the client about the session is to send the session id as part of a URL. In this case, the programmer must encode all URLs sent to the client so that they include the session id. Obviously, cookies are easier to program with, but URL encoding is more portable between browsers. However, URL encoding works only if all the servlets and pages that contain URLs on the site encode them appropriately. This is often too much to ask of a large site, and many simply do not support sessions on browsers that do not support cookies. To encode a URL, use the methods encodeUrl and encodeRedirectUrl in the HttpResponse object.

The values in a session are all objects. On the Java Web Server, it is helpful to make these objects serializable so that they can be saved to disk, if necessary. However, any object will do. If you want to store custom objects, you can also implement the HttpSessionBindingListener interface. In this case, the object is notified when it is added or bound to a session and again when it is unbound. HttpSessionBindingListener defines the methods:

public void valueBound(HttpSessionBindingEvent event)
public void valueUnbound(HttpSessionBindingEvent event)

The server calls these methods when the object is bound and unbound from the session. You might use this notification to update cached information or free resources being held by the object. For example, you might associate objects in a session with Enterprise JavaBeans. When the object is unbound, the relationship can be discontinued.

Normally, it is up to the server configuration to determine when a session is no longer valid. Often this is a question of how much time has passed since the last access, but many servers are configurable. You can also invalidate a session directly by using the invalidate method of HTTPSession.

The following example code shows a simple servlet that keeps a counter for each time the servlet is accessed in the given session. It also prints some of the information provided by the session to the servlet.

The first time this servlet is accessed, it sets the counter to 0 and displays a page like the one in Figure 7.4. Accessing the servlet again displays a page like the one in Figure 7.5.

All the code for this servlet is included in the doGet method. The bold code creates the session and checks whether it is new before constructing the appropriate output. In all cases, a string containing a link back to the servlet is included for the user to press.

import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class SessionInfoServlet extends HttpServlet

{
    public void doGet(HttpServletRequest request,
                      HttpServletResponse response)
    throws ServletException, IOException
    {
        HttpSession session = request.getSession(true);

        response.setContentType(“text/html”);
        PrintWriter out = response.getWriter();

        out.println(“<HTML>”);
        out.println(“<HEAD>”);
        out.println(“<TITLE>”);
        out.println(“Session Info Servlet”);
        out.println(“</TITLE>”);
        out.println(“</HEAD>”);
        out.println(“<BODY>”);

        if(session.isNew())
        {
            out.println(“<H1>New Session</H1>”);
            out.println(“The count is set to 0.”);

            session.putValue(“sessioninfo.count”,new Integer(1));
        }
        else
        {
            Integer count;
            int intCount=0;

            count = (Integer)
                      session.getValue(“sessioninfo.count”);
            if(count != null) intCount = count.intValue()+1;

            out.println(“<H1>Session Information</H1>”);
            out.println(“The count is set to ”+intCount+“.”);
            out.println(“<BR>”);

            session.putValue(“sessioninfo.count”
                               ,new Integer(intCount));

            out.println(“Session ID: ” + session.getId());
            out.println(“<BR>”);
            out.println(“Creation Time: ”
                      + (new Date(session.getCreationTime())));
            out.println(“<BR>”);
            out.println(“Last Accessed Time: ”
                      + (new Date(session.getLastAccessedTime())));
            out.println(“<BR>”);

        }
        out.println(“<A HREF=\”“);
        out.println(response.encodeUrl(request.getServletPath()));
        out.println(“\”>“);
        out.println(“Press Here”);
        out.println(“</A>”);
        out.println(“To reload the page, with url encoding.”);
        out.println(“</BODY>”);
        out.println(“</HTML>”);
        out.close();
    }

}

If you try this servlet, you will find that reloading the Web page increments the counter and updates the last accessed time. Also, if you leave the servlet alone long enough—about 10 to 30 minutes—the session expires, and the next time you access it, you will get a new counter. This expiration time is usually configurable by the server administrator.

Cookies

Sessions provide a method for storing data about a current user interaction, but they are not intended for storing information permanently. Cookies, on the other hand, are key-value pairs that a servlet can associate with a client and that can have an arbitrary expiration time. The drawbacks for cookies are threefold. First, they can only be strings. Second, cookies are stored on the client, so they take up client disk space; as a result most browsers limit their number and size. As a guideline, each server can assign 20 or so cookies to the client, with a total size of 4K. Finally, cookies have to be sent over the Internet with each request. In HTTP, the cookies are part of the header for a request and reply.

Figure 7.4 First time to servlet.

Figure 7.5 Subsequent access to servlet.

The good thing about cookies is that they are easy to program, are flexible, and can be used to store small pieces of information about a particular program on the client’s machine, thus freeing up server resources. Cookies are also associated with a specific server and path, preventing other servers from reading the information they contain. Cookies can be assigned expiration dates, making them persist between sessions. The servlet library uses the class Cookie to represent the cookies provided with an HttpRequest or returned with a response. Table 7.15 shows the methods provided by Cookie.

To determine the cookies for a request, use the HttpServletRequest object’s getCookies method. This returns an array of Cookie objects. To associate cookies with the response, use the HttpServletResponse method addCookie. This call should always happen before you send HTML to the client, because the HTML body may force the HTTP header to be sent, and the cookie must be part of the header. If you have cookies from the response that you want to return to the client, add them using addCookie as well.

Table of Contents