Developers who wish to retain data for unique user sessions in ASP.NET can use an intrinsic feature known as session state.

ASP.NET provides the infrastructure with built-in session-state functionality that enables you to

• Automatically identify and classify requests coming from a single browser client into a logical application session on the server.
• Store session-scoped data on the server for use across multiple browser requests.
• Raise appropriate session-lifetime management events ( Session_Start, Session_End, and so on ) that can be handled in application code.
• Automatically release session data if the browser does not revisit an application within a specified timeout period.

This topic provides an overview of session state; describes how active ASP.NET sessions are identified and tracked; explains the session-state store and general structure; and concludes with a working code example.

HTTP is a stateless protocol, which means that it does not automatically indicate whether a sequence of requests is all from the same client or even whether a single browser instance is still actively viewing a page or site. As a result, building Web applications that need to maintain some cross-request state information ( shopping carts, data scrolling, and so on ) can be extremely challenging without additional infrastructure help.

ASP.NET provides the following support for sessions:

• A session-state facility that is easy to use, familiar to ASP developers, and consistent with other .NET Framework APIs.
• A reliable session-state facility that can survive IIS restarts and worker-process restarts without losing session data.
• A scalable session-state facility that can be used in both Web farm ( multicomputer ) and Web garden ( multiprocess ) scenarios and that enables administrators to allocate more processors to a Web application to improve its scalability.
• A session-state facility that works with browsers that do not support HTTP cookies.
• A throughput equivalent to that of ASP ( or better ) for core session-state scenarios ( 50/50 read/write when putting items into shopping carts, modifying last page visited, validating credit card details, and so on ).