Question

我进行了以下简单测试：

在web.config中，我们有：`sessionState timeout = 40 mode = InProc`
使用`EnableSessionState =＆＃34; ReadOnly＆＃34;`在页面标记中设置
Code Behind：

protected void Page_Load(object sender, EventArgs e)
{

    if (Session["dt"] == null)
        Session["dt"] = DateTime.Now;

    Session["dt"] = ((DateTime)Session["dt"]).AddYears(1);
    Response.Write(Session["dt"].ToString());
}

并发回发的结果如下：

1- 13/11/2015 10:00:00
2- 13/11/2016 10:00:00
3- 13/11/2017 10:00:00
4- 13/11/2018 10:00:00
5- 13/11/2019 10:00:00
6- 13/11/2020 10:00:00
...

明确表示会话变量正在更新。在MSDN上，您可以找到以下内容： http://msdn.microsoft.com/en-us/library/ms178581(v=vs.100).aspx

您可以通过将会话状态模式设置为关闭来禁用应用程序的会话状态。如果要仅为应用程序的特定页面禁用会话状态，可以将@Page指令中的EnableSessionState值设置为false。 EnableSessionState值也可以设置为ReadOnly，以提供对会话变量的只读访问权。

我们在应用程序的几乎每个页面上执行读/写操作。但是，这会阻止同时为同一客户端运行两个http请求。第一个请求应该完成，直到服务器处理第二个请求。经过一些研究，显然是由于会话的独占锁定。为了好奇，我们尝试将会话状态设置为ReadOnly，似乎仍然可以编辑，没有定义独占锁。

问题：

1- Readonly是否意味着Readonly（因此这里有一个asp中的错误）或者其他的东西？

2-只要会话似乎可以使用ReadOnly状态进行编辑，有什么值得担心的，您认为在生产环境中继续使用它是否安全？

由于

Answer 1

这个问题似乎很老，但是有很多观点。只是想向使用只读会话状态并从InProc切换到SQLServer会话的人发出警告。

虽然在只读状态下仍可以将内容放入会话中（没有异常），但是在使用SQLServer会话时，页面完成后这些更改不提交给数据库是这样。

因此，下一页将不会看到您对会话所做的更改，如果您以前曾经将会话设为InProc并且希望它能够看到更改，则可能导致奇怪的副作用。

Answer 2

ReadOnly标志表示您对页面/应用程序的意图。它不是对Session变量的保护。

当您在页面声明上设置ReadOnly时，您只是声明该页面不会更新Session变量。但如果你这样做，那将由你自己承担风险。

声明（以及您的行为）有助于ASP.NET更快。实际上，会话状态模块实现了一种锁定机制，并将对状态值的访问排队。

具有会话状态写入权限的页面将在会话上保留写入程序锁，直到请求完成为止。具有会话状态读取权限的页面将仅在会话上保留读取器锁定，直到请求完成**。

确切地声明每个页面将要使用的会话状态是一种优化页面性能的方法，也是一种保持代码清洁的方法。

最后，您可以通过设置：

完全禁用Session变量（读取和写入）

<sessionState mode="Off">

但我认为这不是你想要的。

Answer 3

更改会话设置：

<sessionState mode="InProc" >

到

<sessionState mode="Off" >

我认为您已经嵌套了web.config文件，因此可能此设置已更改为另一个配置文件。

ASP.Net ReadOnly Session

3 个答案: