10-05-2014, 03:34 PM
SESSION TRACKING
SESSION TRACKING.pdf (Size: 474.81 KB / Downloads: 29)
The Need for Session Tracking
HTTP is a “stateless” protocol: each time a client retrieves a Web page, the client
opens a separate connection to the Web server and the server does not automatically
maintain contextual information about the client. Even with servers that support per-
sistent (keep-alive) HTTP connections and keep sockets open for multiple client
requests that occur in rapid succession, there is no built-in support for maintaining
contextual information. This lack of context causes a number of difficulties. For
example, when clients at an online store add an item to their shopping carts, how
does the server know what’s already in the carts? Similarly, when clients decide to
proceed to checkout, how can the server determine which previously created shop-
ping carts are theirs? These questions seem very simple, yet, because of the inade-
quacies of HTTP, answering them is surprisingly complicated.
There are three typical solutions to this problem: cookies, URL rewriting, and
hidden form fields. The following subsections quickly summarize what would be
required if you had to implement session tracking yourself (without using the built-in
session-tracking API) for each of the three ways.
Cookies
You can use cookies to store an ID for a shopping session; with each subsequent con-
nection, you can look up the current session ID and then use that ID to extract infor-
mation about that session from a lookup table on the server machine. So, there would
really be two tables: one that associates session IDs with user tables, and the user
tables themselves that store user-specific data
Session Tracking in Servlets
Servlets provide an outstanding session-tracking solution: the HttpSession API.
This high-level interface is built on top of cookies or URL rewriting. All servers are
required to support session tracking with cookies, and most have a setting by which
you can globally switch to URL rewriting.
Either way, the servlet author doesn’t need to bother with many of the implemen-
tation details, doesn’t have to explicitly manipulate cookies or information appended
to the URL, and is automatically given a convenient place to store arbitrary objects
that are associated with each session.
Looking Up Information
Associated with a Session
HttpSession objects live on the server; they don’t go back and forth over the net-
work; they’re just automatically associated with the client by a behind-the-scenes
mechanism like cookies or URL rewriting. These session objects have a built-in data
structure (a hash table) in which you can store any number of keys and associated val-
ues. You use session.getAttribute("key") to look up a previously stored
value. The return type is Object, so you must do a typecast to whatever more spe-
cific type of data was associated with that attribute name in the session. The return
value is null if there is no such attribute, so you need to check for null before call-
ing methods on objects associated with sessions