Note that there are some explanatory texts on larger screens.

plurals
  1. POWriting to a read only session in MVC 3+
    primarykey
    data
    text
    <p>I've come across a curious behaviour of ASP sessions. You can force a controller to be outside of the user's session - I want to be able to do this so that multiple requests can execute at the same time and using a session causes them to execute consecutively.</p> <p>Disabling session state works as expected:</p> <pre><code>[SessionState(SessionStateBehavior.Disabled)] public class SampleController : Controller { public ActionResult Test() { // Access to the session should be denied object test = Session["test"]; return Content(test); } } </code></pre> <p>Going to <em>~/Sample/Test</em> will throw a <code>System.Web.HttpException</code>, as expected. However, read-only sessions appear to behave a little strangely:</p> <pre><code>[SessionState(SessionStateBehavior.ReadOnly)] public class SampleController : Controller { public ActionResult Test() { // Read from the session should be fine object test = Session["test"]; return Content(test); } public ActionResult SetTest(string value) { // Write to the session should fail Session["test"] = value; // Read it back from the session object test = Session["test"]; return Content(test); } } </code></pre> <p>So now I expect <em>~/Sample/Test</em> to work, and it does. The odd bit is that the set does too: I go to <em>~/Sample/SetTest?value=foo</em> and it doesn't throw an exception, in fact it returns "foo". If I call <em>~/Sample/SetTest?value=bar</em> and then <em>~/Sample/Test</em> I get "bar", indicating that the session has been written to.</p> <p>So in a <code>SessionStateBehavior.ReadOnly</code> I have successfully written to the session and read my value back.</p> <p>I think this could be due to one of three things:</p> <ul> <li>In MVC 3 <code>[SessionState(SessionStateBehavior.ReadOnly)]</code> is broken/ignored.</li> <li>The <code>[SessionState]</code> is overridden when the session is written to and becomes writeable.</li> <li>The <code>SessionStateBehavior.ReadOnly</code> actually indicates some kind of dirty/optimistic access.</li> </ul> <p>Can anyone confirm?</p> <p>I suspect the last one is true, based off the <a href="http://msdn.microsoft.com/en-us/library/ms178587.aspx">custom session provider documentation</a> - if it is then how does the implementation work? Does writing to a 'read only' session risk concurrency errors (i.e. last write wins) or does it risk corrupt sessions and breaking exceptions?</p> <p><strong>Update</strong></p> <p>It looks like this is by design (from <a href="http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstatestoreproviderbase.aspx">Microsoft's docs</a>):</p> <blockquote> <p>Note that even if the EnableSessionState attribute is marked as ReadOnly, other ASP.NET pages in the same application might be able to write to the session store, so a request for read-only session data from the store might still end up waiting for locked data to be freed.</p> </blockquote> <p>It looks like the second option above is what it actually does - the session is locked and the mode changed to writable.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload