Why Session State?

In networking systems, signaling systems for flow state [8] fall in between two extremes: hard-state and soft-state [32]. In hard-state systems, state is explicitly written once and remains written unless explicitly removed; special mechanisms exist to remove orphaned state. In contrast, in soft-state systems, state automatically expires unless refreshed by the writer, so no such special mechanisms are needed. Session state lies somewhere in between: unlike hard state, its maximum overall lifetime and inter-access interval are bounded, so persistence guarantees need only respect those bounds; unlike soft state, it cannot be reconstructed from other sources if lost, unless the user is asked to repeat all steps that led to the construction of the state.

Nearly all nontrivial Internet services maintain session state, but they either store it as hard state because that is what most storage systems provide, or store it ephemerally (in RAM of otherwise stateless components) because it is cheaper and faster. The former is overkill, the latter does not provide adequate guarantees of persistence, especially in the face of transient failures. Table 2 compares and contrasts the different types of state.

Table 1: Key differences among hard, persistent, soft, and session state.

	Hard/Persistent	Soft/Session
Write Method	Write once	Refresh
Deletion Method	Explicit	Expiration
Orphan Cleanup	Manual	Automatic

For the remainder of this paper, we will use the term ``session state'' to refer to the subcategory of user-session state we now describe. Many associate session state with ``shopping cart,'' but the class of session state we address is significantly broader than just shopping carts. An example of application session state that we address includes user workflow state in enterprise applications. In particular, today's enterprise applications, such as those in J2EE, are often accessed via a web browser. All application state, such as context and workflow, is stored on the server and is an example of what we are calling session state. In essence, user workflow state in enterprise applications is equivalent to temporary application state on a desktop application. Another example of session state is travel itineraries from online travel sites, which capture choices that users have made during the shopping process. Shopping carts can also be an example of session state.

To understand how session state is typically used, we use the example of a user working on a web-based enterprise-scale application to illustrate the typical flow sequence. A large class of applications, including J2EE-based and web applications in general, use the interaction model below:

• User submits a request, and the request is routed to a stateless application server. This server is part of what is often called the middle-tier.

• Application server retrieves the full session state for user (which includes the current application state).
• Application server runs application logic

• Application server writes out entire (possibly modified) session state

• Results are returned to the user's browser

Session state is in the critical path of each interaction, since user context or workflow is stored in session state. Loss of session state is seen as an application failure to the end user, which is usually considered unacceptable to the service provider. Typical session state size is between 3K-200K bytes [37].

Some important properties/qualities of the session state we focus on are listed below. Session state:

1. Is accessed in a serial fashion by a single user (no concurrent access). Each user reads her own state, usually keyed by a deterministic function of the user's ID, so an advanced query mechanism to locate the user's state is unnecessary. Furthermore, the client is typically responsible for storing the necessary metadata to retrieve the state.

2. Is semi-persistent. Session state must be present for a fixed interval $T$, the application-specific session timeout (usually on the order of minutes to hours), but should expire after $T$.

3. Is written out in its entirety, and usually updated on every interaction.

Given these properties, the functionality necessary for a session state store can be greatly simplified, relative to fully-general ACID guarantees provided by a relational datbase. Each simplification corresponds to an entry in the previous numbered list:

1. No synchronization is needed. Since the access pattern corresponds to an access of a single user making serial requests, no conflicting accesses exist, and hence race conditions on state access are avoided, which implies that locking is not needed. In addition, a single-key lookup API is sufficient. Since state is keyed to a particular user and is usually only accessed by that user, a general query mechanism is not needed.
2. State stored by the repository need only be semi-persistent - a temporal, lease-like [16] guarantee is sufficient, rather than the durable-until-deleted guarantee that is made in ACID.
3. Atomic update is sufficient for correctness, since partial writes do not occur. Once session state is modified, any of its previous values may be discarded.

Relative to the specific requirements of session state, SSM does, in a sense, provide ACID guarantees: atomicity and bounded durability are provided, and consistency and isolation are made trivial by the access pattern.

As a generalization, the class of state that we address need not necessarily be single-user; as long as state ownership is explictly passed between parties, which is common in today's enterprise applications [21], the techniques discussed in this paper applies.