Session state is data that's only relevant to a particular user session. Such data should be isolated - and thus not visible to any other user of the same system. Session state is commonly used to store the state of a business transaction in mid-flight, before it's ready for permanent storage (or as I call it - record data). The data in session state is usually not ready for committing to the record data, usually it would fail any validation rules. Often it's not vital to have high durability for session state, in the sense that you may be prepared to tolerate losing it if there's a server crash.

In PofEAA I classified three ways to store session state.

• Client Session State makes the client responsible for storing session state. A rich client can store this on the client machine, for example a web application storing it in the DOM or perhaps something like local storage. Web applications that aren't using javascript can store limited session state in cookies.
• Server Session State relies on the server using a special mechanism for storing session state that is independent of the usual record data. An example of this might be stashing session state in a database designed for rapid key-value access, such as Redis. Older systems often did this in the server's memory, which is effective if you're not concerned about server affinity or the consequences of losing session state on a server crash.
• Database Session State means storing the session data in the same storage scheme as you use for the record data. Usually this means separating session state out into relational tables. If you do this it's important to keep isolation since the point of session state is that it should not be visible outside its session.

While I think this classification is useful, there is the usual blurriness between the cases. If you store session state in a relational database using a key-value style with a Serialized LOB, I'd argue that is server session state even though the data is going in the same database. The distinction between the two is whether you use the usual persistance mechanism or a special persistance mechanism for session data.

You don't have to use one mechanism exclusively. A client that doesn't want to store much client session state will usually need to store at least a key for the session data in client session state with the bulk of the data in one of the server-side mechanisms.

An important alternative to using session state is to use CreationObject.