Session and State Management

Analogy categoryAnalogies

Why State Management Exists

HTTP is inherently stateless -- each request is handled independently, with no built-in memory of prior requests from the same browser -- so ASP.NET MVC provides several mechanisms to simulate continuity: Session state for server-side data that persists across many requests, TempData for a single-redirect handoff, ViewData/ViewBag for passing data from a controller to its own view within one request, and cookies for small pieces of data the browser itself stores and resends. Choosing the wrong mechanism is a common source of bugs: storing a shopping cart in ViewBag, for example, silently loses it on the very next request because ViewBag's lifetime is scoped to a single request-response cycle, not the user's whole visit.

🏏

Cricket analogy: It's like a scorer having to explicitly carry forward the match total between overs rather than the stadium PA system 'remembering' anything on its own -- without a scorebook (state store), every over would start from zero.

Session State: In-Process, State Server, and SQL Server Modes

Session["CartItems"] = cart looks the same in code regardless of where the data actually lives, but the sessionState mode in Web.config determines the real behavior: InProc keeps session data in the worker process's memory, which is fast but wiped on an app pool recycle and unusable across a web farm with multiple servers behind a load balancer; StateServer runs a separate Windows service (aspnet_state) holding session data out-of-process, surviving recycles but requiring objects to be serializable; and SQLServer mode persists session data in a database table, the slowest but most durable option, surviving both recycles and server reboots and working correctly across a load-balanced farm without sticky sessions.

🏏

Cricket analogy: It's like a scorer keeping the scorebook in their own head (InProc) versus writing it on a shared physical sheet in the press box (StateServer) versus filing it with the official league database (SQLServer) -- each survives a shift change differently.

TempData vs. ViewData vs. Cookies

TempData is purpose-built for the Post-Redirect-Get pattern: setting TempData["Message"] = "Order placed!" before a RedirectToAction call preserves that value for exactly one subsequent request (by default backed by Session under the hood), after which it's automatically removed unless explicitly kept with TempData.Keep(). ViewData and its dynamic wrapper ViewBag exist purely to pass data from a controller action to the view rendering that same response -- they do not survive a redirect at all, which is precisely why using ViewBag to carry a success message across a RedirectToAction call silently fails. Cookies, by contrast, live entirely on the client and are resent by the browser on every request to the matching domain/path, making them suitable for small, low-sensitivity preferences like a 'dismiss this banner' flag, but a poor choice for anything larger than roughly 4KB or anything sensitive, since cookie contents are visible to the user and any browser extension unless encrypted.

🏏

Cricket analogy: It's like a captain's instruction shouted to the fielders for just the next single over (TempData) versus a note scribbled only for the current over's field placement (ViewData) versus a permanent laminated card each player keeps in their pocket across the whole match (cookies).

csharp

// Post-Redirect-Get with TempData
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult PlaceOrder(OrderViewModel model)
{
    if (!ModelState.IsValid) return View(model);

    _orderService.Create(model);
    TempData["Message"] = "Order placed successfully!";
    return RedirectToAction("Confirmation");
}

public ActionResult Confirmation()
{
    // TempData survives exactly this one request after the redirect
    ViewBag.Message = TempData["Message"];
    return View();
}

// Session for durable, multi-request cart data
public ActionResult AddToCart(int productId)
{
    var cart = Session["Cart"] as List<int> ?? new List<int>();
    cart.Add(productId);
    Session["Cart"] = cart;
    return RedirectToAction("Index", "Cart");
}

// Web.config: out-of-process session for a load-balanced farm
// <sessionState mode="SQLServer"
//               sqlConnectionString="data source=sql1;user id=sa;password=..."
//               cookieless="false" timeout="20" />

TempData.Keep() re-marks a value for one additional request without re-setting it, useful when a value needs to survive a second redirect hop (for example, Confirmation redirecting again to a receipt page).

InProc session state is lost on every app pool recycle, and IIS recycles app pools routinely (idle timeout, scheduled restarts, memory limits). Never rely on InProc session for anything the business considers durable, like an in-progress checkout total on a production site.

HTTP is stateless; Session, TempData, ViewData/ViewBag, and cookies each simulate continuity differently.
Session mode (InProc, StateServer, SQLServer) determines durability and whether the app can run correctly on a load-balanced farm.
TempData survives exactly one subsequent request after being set, ideal for Post-Redirect-Get success messages.
ViewData/ViewBag only last for the current request-response cycle and do not survive a redirect at all.
Cookies live client-side, are resent automatically, and are unsuitable for large or sensitive data without encryption.
TempData.Keep() extends a value's lifetime by one more request when a value must survive a second redirect.
InProc session is fast but volatile; SQLServer mode is slower but durable and farm-safe.