Article
The JSP Files - Parts 1 to 8: Tagged and Bagged
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 Next
Plan B
The cookie-based approach is quite common; many Web sites use it, because it is flexible, simple, and independent of the server-side language (once the cookie has been saved to the client's hard drive, you can read it using JavaScript, or PHP, or JSP, or ...) The only problem: it is dependent on the cookie being accepted by the client.
And so, another common approach is the use of a "session" to store specific bits of information when a client visits a Web site; this session data is preserved for the duration of the visit, and is usually destroyed on its conclusion. A session can thus be considered a basket of information which contains a host of variable-value pairs; these variable-value pairs exist for the duration of the visit, and can be accessed at any point during it. This approach provides an elegant solution to the "stateless" nature of the protocol, and is used on many of today's largest sites to track and maintain information for personal and commercial transactions.
Every session created is associated with a unique identification string, or "session ID"; this string is sent to the client, while a temporary entry with the same unique identification number is created on the server, either in a flat file or in a database. It now becomes possible to register any number of "session variables" - these are ordinary variables, which can be used to store textual or numeric information, and can be read from, or written to, throughout the session.
The session ID is transmitted to the client either via a cookie, or via the URL GET method. The client, in turn, must reference each request with this session ID, so that the server knows which session each client is associated with and uses the appropriate session variables for each client. In case the client doesn't support cookies and the URL method is rejected or not used, session management capabilities and session variables will not be available to the client, and every request will be treated as though it were coming for the first time.
Sessions are typically left active for as long as the user's browser is open, or for a pre-defined period. Once the user's browser is closed, or the specified time period is exceeded, the session and all variables within it are automatically destroyed.
Session Dissection
Creating a JSP session is much simpler than writing a cookie. To demonstrate this, here's the session equivalent of the cookie-based counter you saw a few pages back.
<html>
<head>
</head>
<body>
<%
// get the value of the session variable
Integer visits = (Integer)session.getValue("counter");
// if null
if (visits == null)
{
// set it to 0 and print a welcome message
visits = new Integer(0);
session.putValue("counter", visits);
out.println("Welcome, stranger!");
}
else
{
// else increment and write the new value
visits = new Integer(visits.intValue() + 1); session.putValue
("counter", visits); out.println("You have visited this
page " + visits + " time(s)! Don't you have anything
else to do, you bum?! "); } %>
</body>
</html>
There isn't much you have to do to create a session - simply use the
putValue() method of the Session object to create one or more session variable, and JSP will automatically create a session and register the variables. You can then use the getValue() method to retrieve the values of the session variables automatically.
An important point to be noted here is that it is necessary to typecast the session variable while using getValue() - in the example above, we've specifically stated the type of the variable in parentheses before assigning it to a regular JSP variable. Since JSP allows you to bind objects to the session, you can bind an Integer object and thereby bypass some of the string-to-number conversion routines in the equvalent cookie example.
With this information in mind, the example above becomes much simpler to read. An "if" statement is used to take care of the two possible
alternatives: a first-time visitor (no prior session) or a returning visitor (pre-existing session). Depending on whether or not the "counter" variable exists, appropriate action is taken.
The Session object also comes with a bunch of other interesting methods - here are some of them:
getId()- returns a string containing the unique session IDsetMaxInactiveInterval(someSeconds)- keeps the session active for someSeconds duration after the last client requestinvalidate()- destroy the sessiongetAttribute()andsetAttribute()- try these ifgetValue()andputValue()don't workgetCreationTime()- returns the time at which this session was created, in seconds, as an offset from midnight January 1 1970
Copyright Melonfire, 2000. All rights reserved.