Home/ Questions/Q 340401
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T10:36:45+00:00

I recently discovered that when you have a page set to session readonly and

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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!

    • 0