Session lock conflict while reading a page in Inproc mode

Question

I recently discovered that when you have a page installed on a readonly session and you use the inproc (in-memory) session store, the session is still writable on this page and is not really read. From the process session repository, it respects read-only configuration.

Do you still have the advantage of not having to block the session when the page is configured to read and use inproc mode? Will multiple simultaneous requests with the same session identifier wait until the session lock is released while reading and inproc?

Answer 1

BuzzAnn,

Microsoft's documentation on this topic indicates that setting the page-level session state mode to "ReadOnly" should protect you from simultaneously trying to write session state information (they will be queued and processed sequentially), but multiple readers are allowed. See Section "Synchronizing access to session state":

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

If the EnableSessionState property of the page is set to "ReadOnly", each page request attempts to obtain a lock on reading status information. In the standard ReaderWriterLock semantics, any number of readers can have simultaneous access to protected information. Any request that reaches a write lock (for example, through EnableSessionState set to true) locks the record and reads session state information until the request containing the write lock completes.

As long as all you are trying to do is read the session state information from your pages, while their EnableSessionState is set to "ReadOnly", all read requests will continue without blocking. However, if you are trying to write, the documentation is not clear what really will happen. Assuming that ReaderWriterLock is all that is used to synchronize access, I assume that you will not be protected from overwriting, race conditions, and other unsynchronized access problems.

If you try to write to the session state, be sure to set EnableSessionState to "true" to ensure that the write lock is reached and synchronization occurs as necessary.

Hope this helps!

Answer 2

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

• enableSessionState="true" is the default behavior and gets a write lock for session data. No other readers or writers can access while this lock is saved.

• enableSessionState="ReadOnly" gets a lock on reading session data. The use of multiple readers is allowed at the same time, but no author can access if any reader has a lock. Unfortunately, any changes you make to the session are local to the request and are not visible to other requests that look at the session object. When you try to change a read-only session, an error does not occur, so this behavior is not obvious with the first blush.

• enableSessionState="false" does not receive any lock. The HttpContext.Session property is set to zero, and your page will not have access to session data.