Rationale Behind IReadOnlySessionState

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 l开发者_Python百科ean 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.

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.

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.