无法使用带有 SQL 的通用会话状态提供程序跨实例访问会话状态
我有一个包含 Web 应用程序的 Azure 项目。它在计算模拟器中使用两个实例运行。我已经添加了会话状态的通用提供程序，目前将其指向 SQL Express 数据库。
创建会话时，我可以看到它在数据库中创建。
当我向会话状态添加某些内容时，它似乎已存储到数据库中。我说出现是因为我实际上没有反序列化数据......我只是看到正在进行写入，并且在同一个实例上数据反序列化得很好。
但问题是，如果我碰巧连接到第二个实例，则会话数据不可用。如果在第二个实例中我将数据存储到会话中，那么该数据将作为新会话写入数据库。事实是，会话 ID 在会话 cookie 中保持不变，但数据库表为每个实例创建新记录：
表中的会话 ID：
0gong5ihsrjakfzry53e4rtm/LM/W3SVC/1273337584/ROOT 0gong5ihsrjakfzry53e4rtm/LM/W3SVC/1273337585/ROOT
为了测试，我尝试更改 web.config 中的 applicationName 并设置 cookieless=false。
知道出了什么问题吗？
I have an Azure project that contains a web application. It runs with two instances in the compute emulator. I've added the universal provider for session state and am currently pointing it to a SQL Express database.
When a session is created I can see it being created in the database.
When I add something into the session state it appears to be stored into the database. I say appears because I haven't actually deserialized the data... I just see writes being made, and on the same instance the data deserializes fine.
The problem though is that if I happen to connect to the second instance the session data isn't available. If on the second instance I store data into the session, that then gets written to the database as a new session. Thing is, the session ID stays the same in the session cookie, but the database table creates new records for each instance:
SessionID in table:
0gong5ihsrjakfzry53e4rtm/LM/W3SVC/1273337584/ROOT
0gong5ihsrjakfzry53e4rtm/LM/W3SVC/1273337585/ROOT
For the sake of testing I tried changing the applicationName in the web.config and set cookieless=false.
Any idea what is going wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当您部署应用程序时，您是否观察到相同的行为？我相信这是在模拟器中观察到的问题，但在 Azure 本身上，它按预期工作。
请参阅 MSDN 论坛上的此主题 的解决方法。
Have you observed the same behaviour when you've deployed your application? I believe it's an issue that's been observed in the emulator, but on Azure itself, it works as expected.
See this thread on the MSDN Forums for a workaround.