What are session locks?
With the design of ASP.NET comes session variables. These variables enable the application to keep track of individual sessions.
Every request to a handler that has session state enabled will take a read or write lock. If you have an unlucky mix of requests, you can end up with many requests blocked while waiting for the 1 request with the lock to finish.
How does it work?
1. Request is made to my-page.aspx, meanwhile 2 other requests are made shortly after. These 2 new requests will wait in the AcquireRequestState until my-page.aspx finishes executing, releasing the lock.
2. The initial request, my-page.aspx, executes its respective code.
3. my-page.aspx enters the ReleaseRequestState once done, releasing the session lock for other requests to obtain.
If my-page.aspx takes 10 seconds to run, then the following requests will take a minimum of 10 seconds to execute, no matter how fast they are.
How do I identify session locks?
1. LeanSentry will diagnose 'Session lock'
2. The diagnostic will show the function that took the lock
3. The blocked requests tab will show the exact request that took the lock
How do I resolve session locking?
- Best solution: completely move away from session state, as many have done. You can often reduce session locking by moving a bunch of state from sessions into cookies or app-wide caches. (Just be careful to avoid lock contention when centralizing per-user state into app-level state)
- Short term solution: reduce blocking by turning off session state or making it read-only for all pages that don't need write access, limiting write access to only pages that need it. (Read-only session state requests don't block for each other, but they do block for a write-enabled session state request)
- If 1 & 2 not possible: Optimize blocking function that took the lock, and make it execute quicker.