IRequiresSessionState 和IReadOnlySessionState 除了无法保存对会话变量的更改之外，还有什么区别？
两者都让我能够访问我的HttpHandler 中的会话变量。但为什么我更喜欢IReadOnlySessionState？它只是限制我为下一个请求保存会话。
还是它给我带来了优于IRequiresSessionState 的性能优势？
我什么时候更喜欢使用IReadOnlySessionState 而不是IRequiresSessionState？
【问题讨论】：
标签： c# asp.net session-state httphandler
一个关键的区别是 IRequiresSessionState 对当前会话设置了排他锁，从而可能限制来自当前用户的并发请求数。 （有关此锁定现象的更多背景信息，请参阅Is it possible to force request concurrency when using ASP.NET sessions?）
相比之下，IReadOnlySessionState 不获取排他锁。
这与renad's helpful answer to an almost identical SO question 中记录的内容相同。
我为此找到的最佳官方文档来自 MSDN 文章Session State Providers：
会话状态提供程序中三个最重要的方法是 GetItem、GetItemExclusive 和 SetAndReleaseItemExclusive。前两个由 SessionStateModule 调用以从数据源检索会话。如果请求的页面实现了 IRequiresSessionState 接口（默认情况下，所有页面都实现了 IRequiresSessionState），则 SessionStateModule 的 AcquireRequestState 事件处理程序调用会话状态提供程序的 GetItemExclusive 方法。方法名称中的“独占”一词意味着只有当另一个请求当前未使用该会话时才应检索该会话。另一方面，如果请求的页面实现了 IReadOnlySessionState 接口（实现这一点的最常见方法是在页面的 @Page 指令中包含 EnableSessionState="ReadOnly" 属性），则 SessionStateModule 调用提供者的 GetItem 方法。这里不需要排他性，因为 SessionStateModule 允许重叠的读取访问。
注意显式使用这些接口和使用EnableSessionState Page 指令之间的相似之处：
【讨论】：
该接口控制框架是否将在请求结束时保存当前会话状态。当您使用进程外会话状态存储时，它会产生更大的差异。在这种情况下，如果没有接口，系统仍然会将会话数据存储在远程数据库中，即使它没有更改（系统不会跟踪会话数据是否在请求期间被修改）。使用 IReadOnlySessionState 接口时，会跳过回写阶段。
【讨论】：
关注这个http://msdn.microsoft.com/en-us/library/system.web.sessionstate.irequiressessionstate.aspx
IRequiresSessionState 派生自 System.Web.SessionState 使用这个接口我们可以访问 Httphandler 和 Class 文件中的 session
如果您需要对 Session 进行只读访问，请实现 IReadOnlySessionState 接口。
【讨论】：
IRequiresSessionState 是做什么用的，但是为什么IReadOnlySessionState 存在呢？为什么我更喜欢使用它？