问题:

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.

回答1:

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.

回答2:

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.