4

I just implemented a handler that uses IReadOnlySessionState and was wondering why this marker interface is needed. (I understand that it is needed in order to access Session variables, my question is why is this from a framework designer's perspective) My thinking is that it is so handlers can be as lean as possible, requiring them to "opt-in" if they want to make use of session-state, but I'm wondering if perhaps I'm missing something else.

heisenberg
  • 9,665
  • 1
  • 30
  • 38
  • See also http://stackoverflow.com/questions/8039014/irequiressessionstate-vs-ireadonlysessionstate/12504420 – Chris Sep 20 '12 at 18:24
  • Possible duplicate of [IRequiresSessionState vs IReadOnlySessionState](https://stackoverflow.com/questions/8039014/irequiressessionstate-vs-ireadonlysessionstate) – Nisarg Shah Feb 08 '18 at 08:51

2 Answers2

8

You're right. IReadOnlySessionState interface just gives you possibility to use Context.Session object.

But if you implement IRequiresSessionState interface, your handler puts exclusive lock on current session, so all other requests (which wants to use Session object) in context of the same session will wait until your handler finishes.

IReadOnlySessionState isn't very good name, because actually you can modify SessionState in such handlers and you won't get an exception. You just take responsibility for concurrent problems on you.

renadeen
  • 1,741
  • 17
  • 16
  • I thought the claim was that if you set IReadOnlySessionState, you could make changes (eg Session["x"] = 3) and those changes would "stick", affecting future accesses of Session["x"] -- the only difference being avoiding the exclusive lock being taken out. However I'm having trouble reproducing this; IReadOnlySessionState does allow you to make changes to the Session without seeing an exception, but the changes seem to be forgotten once the handler exits. If the claim is that the changes *do* stick, any tips to reproduce? – Chris Sep 20 '12 at 00:15
  • I reproduced this without any problem. Create asp.net project, in Default.aspx add `<%=Session["t"]%>` – renadeen Sep 24 '12 at 04:34
  • @Chris I reproduced this without any problem. Create asp.net project, add `<%=Session["t"]%>` to markup of Default.aspx, set EnableSessionState="true", add `Session["t"] = ((int) (Session["t"] ?? 1) ) + 1;` to Default.aspx.cs (in Page_Load), launch site and refresh page several times. Counter will increment each refresh.(Didn't know that I can edit comment only for five minutes. Very annoying.) – renadeen Sep 24 '12 at 04:43
  • Yes, EnableSessionState="true" (the page-markup equivalent of IRequiresSessionState) will behave as you describe. I thought you were *also* implying that if the page had EnableSessionState="ReadOnly" (the page-markup equivalent of IReadOnlySessionState), then it would also behave this way -- which is incorrect. (With "ReadOnly", the counter does *not* increment when you reload the page.) I probably misunderstood your original post. I'd say "With IReadOnlySessionState you can modify SessionState without getting an exception - but your changes won't persist through the next HTTP request." – Chris Sep 25 '12 at 01:37
  • @Chris I am sorry, I've made a mistake in my comment, I meant set EnableSessionState="ReadOnly" and the counter will increment each refresh. That means changes _persist_ through next HTTP request. – renadeen Sep 25 '12 at 11:00
  • Strange - your example code doesn't work for me with EnableSessionState="ReadOnly"; the counter doesn't increase, nor does the ASP.NET session cookie ever get set (as indicated by Fiddler). Could it be a version thing? I'm using VS2005/Win7/64-bit. I tried using both the VS debug web server and under IIS. – Chris Sep 25 '12 at 19:26
  • I'm using VS2010/asp.net4.0/Win7/64-bit. Maybe this behaviour was changed in asp.net 3.0 or 4.0. – renadeen Sep 26 '12 at 05:21
  • @Chris, it probably depends on your choice of session store. An in-process session will probably "stick", but any of the out-of-process options (like state server) should not - sessions only get serialized back to the out-of-state store if your handler is IRequiresSessionState or, for a page, EnableSessionState="true" – MattW Oct 22 '13 at 17:19
  • With the setup described by renadeen and the `EnableSessionState="ReadOnly"`, the write to session state is not persisted across calls. The **simplified** reason is that the for pages marked ReadOnly, at the beginning of the request the session state is fetched without locks and at the end of the call, if the session state has no lock, it is not saved/persisted. Look [Here](http://stackoverflow.com/questions/8989648/replacing-asp-nets-session-entirely) and [Here](http://stackoverflow.com/questions/8939188/writing-to-a-read-only-session-in-mvc-3). Also, link in the question comments is great. – Umair Ishaq Dec 12 '13 at 16:37
3

Yes, AFAIK, you are correct. Both IReadOnlySessionState and IRequiresSessionState are marker interfaces that protect you from making your handler heavier, and slower.

The difference between them is only the write status of the session.

SWeko
  • 30,434
  • 10
  • 71
  • 106