ASP.Net ReadOnly Session

Question

I've conducted the following simple test:

1. In web.config, we have: `sessionState timeout=40 mode=InProc `
2. Empty page with `EnableSessionState = "ReadOnly"` set in page tag
3. Code Behind:

protected void Page_Load(object sender, EventArgs e)
{

    if (Session["dt"] == null)
        Session["dt"] = DateTime.Now;

    Session["dt"] = ((DateTime)Session["dt"]).AddYears(1);
    Response.Write(Session["dt"].ToString());
}

The result for concurrent post backs will bee as the following:

1- 13/11/2015 10:00:00
2- 13/11/2016 10:00:00
3- 13/11/2017 10:00:00
4- 13/11/2018 10:00:00
5- 13/11/2019 10:00:00
6- 13/11/2020 10:00:00
...

Which clearly says that the session variable is getting updated. On MSDN you can find the following: http://msdn.microsoft.com/en-us/library/ms178581(v=vs.100).aspx

You can disable session state for an application by setting the session-state mode to Off. If you want to disable session state for only a particular page of an application, you can set the EnableSessionState value in the @ Page directive to false. The EnableSessionState value can also be set to ReadOnly to provide read-only access to session variables.

We performs read/write operations on almost every page in our application. However, this is preventing running two http requests for the same client at the same time. The first request should be finished until the server process the second one. After some researches, it was clearly due to exclusive locks on session. For curiosity, we have tried to set session state to ReadOnly and it seems still editable which no exclusive locks are defined.

Questions:

1- Does Readonly means Readonly (so there is a bug in asp here) or it's something else?

2- As long as session seems to be editable with ReadOnly state, is there anything to worry about, do you think it's safe to keep using it like this on production environment?

Thanks

Answer 1

This question seems old, but has quite a lot of views. Just wanted to give a warning to people using read-only session states and switching from InProc to SQLServer sessions.

While you can still put stuff in your session when it is read-only (without getting an exception), when using SQLServer sessions these changes are not committed to the database when the page has finished doing it's thing.

So the next page will not see your changes to the session, which may lead to strange side-effects if you used to have your session as InProc before and are expecting it to see the changes.