| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
1. How can session state be maintained in the web tier?
A session is a sequence of service requests by a single user using a single client to access a server. The information maintained in the session across requests is called session state. Session state may include both information visible to the user (shopping cart contents, for example) and invisible application control information (such as user preferences).
HttpSession.
HttpSession frees the developer from the details of
session state management, and ensures portability and scalability
of web components. Further benefits of web-tier session management
are discussed below.
2. What is the best way to manage session state from the web tier?
Application servers typically implement interface
HttpSession using some combination of cookies and/or URL
rewriting to store a session ID on the client. The session id
identifies the session, and the server is responsible for identifying
the appropriate HttpSession object and associating it
with the HttpServletRequest. All of the details of
cookies and URL rewriting are handled by the object that implements
HttpSession. The Session Tracking section
of the Java Servlet Tutorial (at
http://java.sun.com/docs/books/tutorial/servlets/client-state/session-tracking.html)
explains how to manage sessions.
HttpSession implementations differ
between application servers. Implementations of this interface
may be vulnerable to some of the drawbacks of client-side state
described in
Session state in the client tier, since most such implementations
store at least a session ID in the client tier.
How does the web tier maintain session state?
A web container provides session management to the JSP pages and servlets
it contains by way of interface
HttpSession. Typically, the container will try to use a
cookie to save user session state on the client. If the client refuses
to accept the cookie for some reason (the user has disabled cookies,
an intervening firewall filters cookies, etc.), the container will
usually try to implement session management by using URL rewriting.
URL rewriting works in cases where cookies will not, even in browsers
that don't implement cookies, but suffer from other
problems. Rewritten URLs tend to be long and ugly, are expensive to
produce for pages with many links, and usually don't "bookmark"
well. Furthermore, rewritten URLs usually can't be used with legacy
web pages, because the URLs in the links in those pages are static.
HttpSession object itself, using its methods
getAttribute() and setAttribute(). Using
these methods allows the web container to maintain that session state
in a way most effective for your particular application and server.
3. What are some advantages of storing state in the web tier?
HttpSession, the developer is freed from bothering with
the details of designing, implementing, and testing code for managing
session state.
HttpSession implementation is
optimized and tested for that server, and therefore will probably be
more efficient and reliable than a custom solution.
HttpSession interface is standardized, and so must
pass the J2EE Compatibility Test Suite (CTS) across all
J2EE-branded application servers. Read about the role of the
CTS and J2EE branding to ensure portability at
http://java.sun.com/j2ee/compatibility.html.
HttpSession, it can most effectively manage storage
of that state in caches and/or server clusters.
HttpSession implementation that works properly today
will work better tomorrow as improved server versions become
available, with little or no change to the source code.
4. What are potential disadvantages with storing state on the web tier?
HttpSession interface is limited to HTTP
communications. Other types of clients will require reimplementation
of session state management.