Skip to main content

Anti-Pattern: Session Locking (The Queue)

Description​

ASP.NET (classic) imposes a Reader/Writer lock on Session state. By default, any controller/handler that requires Session state acquires a Write Lock. This means concurrent requests from the same session (same user) are strictly serialized (executed one after another).

Impact​

  • Latency: If a page attempts to load 5 AJAX widgets in parallel, and each widget takes 1 second, the total load time is 5 seconds (1+1+1+1+1) instead of 1 second.
  • User Experience: The application feels unresponsive during long-running requests (e.g., generating a PDF) because the user cannot navigate to any other page (the new request waits for the lock).

Detection​

Any Controller that uses Session[...] or does not explicitly opt-out via SessionStateBehavior.

# Forensic Grep: Find usage of Session state
grep -r "Session\[" . --include="*.cs" --include="*.cshtml"

Refactoring​

1. ReadOnly Session​

If a controller only reads from session, mark it as ReadOnly. This allows concurrent execution.

[SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)]
public class DashboardController : Controller { ... }

2. Disable Session​

If a controller (e.g., API) doesn't need session at all.

[SessionState(System.Web.SessionState.SessionStateBehavior.Disabled)]
public class ApiController : Controller { ... }

3. Store Less​

Avoid using Session for temporary data storage. Use Cache (for shared data) or RequestContext (for per-request data). Proactively manage UX Complexity Budgets to avoid "Lock Congestion".

2026 Audit Findings​

  • Occurrences: High (>100 active uses).
  • Severity: Medium (UX Latency).
  • Analysis: Widespread use of Session["Key"] in Controllers and Views enforces serial request processing.