3.2.1 Abstract Data Model

This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.

An application that operates in a stateless manner can need to store data that is associated with certain transient operations. If a unique identifier is flowed from one transient operation to another, it is possible for an application to externally store data that is keyed to this unique identifier. Client applications can load this data by providing a unique key to a state server implementation.<8>

A state server provides the service for externally storing such data. It operates against a virtual storage model, where individual pieces of data are indexed by using a unique identifier. Each unique identifier points at a table of name-value pairs that contain session state information.

When a client requests session state information, the server finds the unique identifier and returns the name-value pairs that are associated with that key. When a client updates session state information, it provides the state server with the unique key and a set of name-value pairs. The state server stores the name-value pairs and associates them with the unique key for subsequent retrieval.

The state server supports basic locking semantics to ensure that concurrent read and write attempts do not corrupt session state.