|
|
Start of Tutorial > Start of Trail > Start of Lesson | Search |
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
HttpSessionobject) for a user.
- Store or get data from the
HttpSessionobject.
- Invalidate the session (optional).
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();
...
}
}
The HttpSession interface provides methods that store and
return:
:
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.
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();
...
}
}
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 |