- How can session state be maintained in the web tier?
- What is the best way to manage session state from the web tier?
- What are some advantages of storing state in the web tier?
- What are potential disadvantages with storing state on the web tier?
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).
We recommend that:
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.
Be aware that the 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.
In general, it's preferable to save custom session state in the
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?
-
Easy implementation.
Since the application server handles the implementation of
HttpSession, the developer is freed from bothering with
the details of designing, implementing, and testing code for managing
session state.
-
High-quality, efficient operation.
An application server's
HttpSession implementation is
optimized and tested for that server, and therefore will probably be
more efficient and reliable than a custom solution.
-
Potentially richer feature set. An application server's
implementation of session state management may include such features
as failover, cluster support, and so on, that go beyond the base-level
requirements of the J2EE platform specifications. The system
architect can select a server platform with the differentiating
features that best suit the application requirements, while
maintaining J2EE technology compatibility and portability.
-
Portability.
The
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.
-
Scalability.
When the application is allowed to manage session state by way of
HttpSession, it can most effectively manage storage
of that state in caches and/or server clusters.
-
Evolvability.
Application server vendors are constantly improving their offerings.
Servers will maintain existing interfaces for backward compatibility,
even as they add features that improve performance and reliability.
An
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?
-
Limited to web clients.
The web tier is by definition limited to servicing web clients (though
HTML "screen scraping" or XML-over-HTTP may overcome this limitation
somewhat). The
HttpSession interface is limited to HTTP
communications. Other types of clients will require reimplementation
of session state management.
-
Session state not guaranteed to survive web container crashes.
Some application servers persist session state or provide failover, so
sessions can span container crashes or restarts. But not all servers
support that functionality, since the specification doesn't require
it. As a result, restarting a container can invalidate all sessions
in progress, losing all of their associated state. If
this is a problem for your application, consider either selecting a
server that provides session failover, or consider storing
session state in the EIS tier. (The latter option has
some problems discussed in the referenced document.)
|
|
Print-friendly Version
