Session State in Web Forms

Session state, exposed through the HttpSessionState object accessible as Session in any page or user control, is a server-side, per-user dictionary of key-value pairs that persists across multiple requests from the same browser, unlike Page-level ViewState which only survives a single postback. The server identifies which Session belongs to which visitor via a SessionID, typically transmitted in a cookie (ASP.NET_SessionId), and common uses include a shopping cart, a multi-step wizard's in-progress data, or caching a logged-in user's profile so it doesn't need to be reloaded from the database on every page. Because Session is per-user and stored server-side, it consumes server memory or external storage for every active visitor, unlike Cache, which is a shared pool of data intended for reuse across all users.

The <sessionState> element in web.config's mode attribute controls where session data physically lives: InProc keeps it in the worker process's own memory, which is the fastest option but is lost entirely whenever the app pool recycles or the server restarts, and doesn't work correctly across a load-balanced web farm without sticky sessions. StateServer stores session data in a separate Windows service (aspnet_state) that can run on its own machine, surviving individual app pool recycles and working across a web farm, but every stored object must be serializable since it's copied out of process. SQLServer mode persists session data in a SQL Server database (via InProc or out-of-process serialization), the slowest but most durable option, surviving both app pool recycles and full server reboots, which matters for applications that can't tolerate losing an in-progress shopping cart during a deployment.

Global.asax exposes Session_Start, which fires the first time a new visitor's Session is touched, and Session_End, which fires when a session expires or is explicitly abandoned — though Session_End only fires reliably in InProc mode, since StateServer and SQLServer modes don't notify the application when a session times out. Session.Timeout, defaulting to 20 minutes, controls how long a session stays valid after the last request from that visitor before it's discarded, and calling Session.Abandon() immediately ends the current session, commonly used on a logout page to clear any cart or authentication data right away rather than waiting for the timeout to elapse. By default, sessions are tracked via a cookie, but cookieless="true" in web.config embeds the SessionID directly in the URL instead, useful for clients that block cookies but risky because that ID can then leak through referrer headers or bookmarked links.

Storing large or numerous objects in Session under InProc mode inflates the worker process's memory footprint for every concurrently active user, and since that memory is never reclaimed until the session times out or the app pool recycles, a busy site with bloated sessions can suffer memory pressure and even OutOfMemoryExceptions. In a load-balanced web farm, InProc sessions require configuring sticky sessions (also called session affinity) at the load balancer so a user's requests always land on the same server, since another server has no access to that in-memory data; switching to StateServer or SQLServer mode removes this constraint but requires every object stored in Session to be serializable. Finally, because a single browser can fire multiple concurrent requests (for example, two frames or an AJAX call alongside a normal postback), Session access isn't inherently thread-safe across those simultaneous requests to the same session, which can produce subtle race conditions if code assumes exclusive access.