Questions and Answers - Platform Technologies
- How and where should session state be maintained?
1. How and where should session state be maintained?
Client-server systems are defined by servers providing information
services to clients. Usually, there are more clients than servers, so
servers need a way to keep track of which client is which. A "session"
is a single client's conversation (usually involving many
request/response roundtrips) with a logical server (which may be
formed of one or more physical servers). Session state is
client-specific data that is accumulated during the session.
For the purposes of this discussion, session state is any information
relating to a particular user's interaction with a J2EE application in
a single session. User name, user preferences, and shopping cart
contents are all examples of session state in the Java Pet Store
sample application.
Originally, Web servers supported no concept of session or of session
state. Since HTTP is a stateless protocol, the original HTTP servers
maintained no information (other than logs) about each service request
once the request was completed. As a result, users were
indistinguishable from one another, and there was no way for a user to
accumulate information over a series of service requests,
for use in a subsequent transaction.
As Web applications have become more sophisticated, several mechanisms
for maintaining user sessions, and the state associated with them,
have developed. Multitier Web applications may now store session state
in one or more of the application tiers. Selecting the appropriate
tier(s) for application state is a crucial choice in a design.
The J2EE BluePrints application programming model defines applications
in terms of several tiers. (The tiers and their relationships appear
in "J2EE
Platform Overview".)
The tradeoffs involved in selecting a particular tier for storing
session state are discussed in the "Questions and Answers" sections
for each tier, and are summarized below:
-
The Client tier.
Storing all state for a session in the Client tier can
help simplify server implementation, but may cause security and
bandwidth problems.
-
The Web tier.
Web-tier session state is lightweight and easy to implement with
standard APIs, but is difficult to scale and is limited to HTTP
clients. Still, if not using Enterprise JavaBeans, we recommend that
HttpSession
be used to track session state.
-
The EJB tier.
Stateful session beans provide the easiest and most robust way to
handle session state, but obviously incur the overhead of an
Enterprise JavaBeans technology-enabled server.
-
The EIS tier.
Maintaining session state in the EIS tier (usually the database) may
be worthwhile in some situations, but this approach can cause
performance bottlenecks. EIS-tier session state may be persisted by
using entity beans, or the Web tier may persist session state directly
to a database.
See the relevant section linked from the list above for discussions of
the mechanisms and tradeoffs involved in storing session state at each
tier of a J2EE application.
Print-friendly Version
