Existing Solutions

Frequently, enterprises use either a relational database (DB) or a filesystem or filesystem appliance (FS) to store session state, because they already use a DB or FS for persistent state. There are several drawbacks to using either a DB or FS, besides the costs of additional licenses, which are detailed in previous work [26].

In addition, DB and file systems are well-known to be difficult to administer and tune. Each must be configured and tuned for a particular workload. Even for a skilled and costly administrator, this remains a difficult and often error-prone process that is repeated as the workload changes.

In contrast, in-memory solutions avoid several of the drawbacks of FS/DB, and are generally faster, but make do not provide both performance and correctness guarantees. Existing in-memory solutions require a user to be pinned to a particular server, which prevents the application-processing tier from remaining truly stateless, since each server must both run application logic and store session state. Because of pinning, load-balancing can only be done across users but not across requests, and hotspots are harder to alleviate. A detailed discussion of in-memory solutions can be found in previous work [25,26].