Session Lock Contention with Page Readonly in Inproc Mode

Question

I recently discovered that when you have a page set to session readonly and you are using inproc (in memory) session storage, the session is still writable on that page and is not truly read only. Out of process session storage does respect the readonly setting.

Do you still get the benefit of having no session lock contention when a page is set to readonly and using inproc mode? Will multiple simultaneous requests with the same session Id have to wait for the session lock to release when in readonly and inproc?

Answer 1

See this blog post: Handling multiple simultaneous requests from a user in ASP.NET:

• enableSessionState="true" is the default behavior, and acquires a writer lock on session data. No other readers or writers can gain access while this lock is held.

• enableSessionState="ReadOnly" acquires a reader lock on session data. Multiple readers are allowed simultaneously, but no writer can gain access if any reader holds a lock. Unfortunately, any changes you make to session are local to the request and not visible to other requests that look at the session object. No error is thrown if you try to modify a "read only" session, so this behavior is not obvious at first blush.

• enableSessionState="false" doesn't acquire any lock. The HttpContext.Session property ends up being null, and your page will have no access to session data.

Answer 2

BuzzAnn,

Microsoft's documentation on the topic indicates that setting your page-level session state mode to "ReadOnly" should safeguard you against concurrent attempts to write session state information (they'll queue and be handled serially), but multiple readers will be allowed. See the "Synchronizing Access to the Session State" section:

http://msdn.microsoft.com/en-us/library/aa479041.aspx

When the EnableSessionState property for a page is set to "ReadOnly," each page request attempts to get a reader lock on the state information. In standard ReaderWriterLock semantics, any number of readers can have concurrent access to the information being protected. Any request that achieves a writer lock (e.g., through EnableSessionState being set to "true"), though, will block writes and reads on the session state information until the request holding the writer lock completes.

As long as all you're trying to do is read session state information from your pages while they have EnableSessionState set to "ReadOnly," all read requests will proceed without blocking. If you attempt to write, though, the documentation isn't clear about what will actually happen. Assuming a ReaderWriterLock is all that's being used to synchronize access, my guess is that you won't be protected against overwrites, race conditions, and other non-synchronized access problems.

If you're going to attempt to write to session state, be sure to set EnableSessionState to "true" to ensure that a writer lock is achieved and synchronization occurs as is needed.

I hope this helps!