Motivation
Stores session data as committed data in the database.
Summary
When a call goes out from the client to the server, the server object first pulls the data required for the request from the database. Then it does the work it needs to do and saves back to the database all the data required.
In order to pull information from the database, the server object will need some information about the session, which requires at least a session ID number to be stored on the client. Usually, however, this information is nothing more than the appropriate set of keys needed to find the appropriate amount of data in the database.
The data involved is typically a mix of session data that's only local to the current interaction and committed data that's relevant to all interactions.
When to Use
Database Session State is one alternative to handling session state; it should be compared with Server Session State and Client Session State.
Clustering and failover with Database Session State are usually more straightforward, at least with the regular solutions.
Specific Considerations
The first aspect to consider with this pattern is performance. You'll gain by using stateless objects on the server, thus enabling pooling and easy clustering. However, you'll pay with the time needed to pull the data in and out of the database with each request. You can reduce this cost by caching the server object so you won't have to read the data out of the database whenever the cache is hit, but you'll still pay the write costs.
The second main issue is the programming effort, most of which centers around handling session state. If you have no session state and are able to save all your data as record data in each request, this pattern is an obvious choice because you lose nothing in either effort or performance (if you cache your server objects).
References