IRequiresSessionState 与 IReadOnlySessionState
除了无法保存对会话变量的更改之外，IRequiresSessionState 和 IReadOnlySessionState 之间还有什么区别？
两者都使我能够访问 HttpHandler 中的会话变量。但为什么我更喜欢IReadOnlySessionState？它只是限制我保存下一个请求的会话。
或者它是否给我带来了优于 IRequiresSessionState 的性能优势？
我什么时候更愿意使用 IReadOnlySessionState 而不是 IRequiresSessionState？
What is the difference between IRequiresSessionState and IReadOnlySessionState beside the inability of the second to save changes to the session variables?
Both provide me the ability to access session variables in my HttpHandler. But why would I prefer IReadOnlySessionState? It just restricts me from saving the session for the next request.
Or does it gives me an performance advantage over IRequiresSessionState?
When would I prefer to use IReadOnlySessionState over IRequiresSessionState?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一个关键的区别是 IRequiresSessionState 对当前会话设置了独占锁，从而可能限制当前用户的并发请求数。 （有关此锁定现象的更多背景信息，请参阅 使用 ASP.NET 会话时是否可以强制请求并发？）
相比之下，IReadOnlySessionState 不会获取独占锁。
这与 renad 对几乎相同的 SO 问题的有用答案中记录的内容相同。
我找到的最好的官方文档来自 MSDN 文章 会话状态提供程序：
请注意显式使用这些接口与使用 之间的相似之处EnableSessionState 页面指令：
One critical difference is that IRequiresSessionState puts an exclusive lock on the current session, thereby potentially limiting the # of concurrent requests from the current user. (For more background on this locking phenomenon, see Is it possible to force request concurrency when using ASP.NET sessions?)
In contrast, IReadOnlySessionState does not acquire an exclusive lock.
This is the same thing documented in renad's helpful answer to an almost identical SO question.
The best official documentation I've found for this is from MSDN article Session State Providers:
Note the parallel between explicitly using these interfaces and using the EnableSessionState Page directive:
该接口控制框架是否在请求结束时保存当前会话状态。当您使用进程外会话状态存储时，它会产生更大的差异。在这种情况下，如果没有该接口，系统仍会将会话数据存储在远程数据库中，即使它没有更改（系统不会跟踪会话数据在请求期间是否被修改）。当您使用 IReadOnlySessionState 接口时，会跳过写回阶段。
That interface controls whether the framework will save the current session state at the end of the request. It makes a bigger difference when you're using out-of-process session state storage. In that case, without the interface, the system will still store the session data in the remote database, even when it hasn't changed (the system doesn't keep track of whether the session data was modified during the request). When you use the IReadOnlySessionState interface, the write-back phase is skipped.
请遵循此 http://msdn.microsoft.com/en -us/library/system.web.sessionstate.irequiressessionstate.aspx
IRequiresSessionState 派生自 System.Web.SessionState
使用此接口，我们可以访问 Httphandler 和 Class 文件中的会话。
如果需要对会话进行只读访问，请实现 IReadOnlySessionState 接口。
Follow this http://msdn.microsoft.com/en-us/library/system.web.sessionstate.irequiressessionstate.aspx
IRequiresSessionState is derived from System.Web.SessionState
using this interface we access session in Httphandler and Class file
If you need read-only access to the Session, implement the IReadOnlySessionState interface.