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

The ReadOnly flag indicates just your intention for the page/application. It is not a protection for the Session variable.

When you set ReadOnly on a page declaration you are just declaring the page will not update the Session variable. But if then you do it, it is at your own risk.

The declararion (and your behavior) helps ASP.NET to be faster. In fact, the session state module implements a locking mechanism and queues the access to state values.

A page that has session-state write access will hold a writer lock on the session until the request finishes. A page that has session-state read access will hold just a reader lock on the session until the request finishes**.

Declaring exactly the use of the session state that each page is going to make is a way to optimize the performance of the page and also a way to keep the code clean.

Finally you can completely disable the Session variable (both read and write) by setting:

<sessionState mode="Off">

but I do not think it is what you want.

Answer 2

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.

Answer 3

Change the session settings:

<sessionState mode="InProc" >

to

<sessionState mode="Off" >

I think you've nested web.config file so maybe this setting has been changed into another config file.