InProc 会话数据消失
我大约一周前才注意到这一点。我正在存储有关用户正在玩的当前谜题（www.wikipediamaze.com）的数据，如下所示：
HttpContext.Current.Session.Add("puzzleInfo", currentPuzzleInfo);
我知道使用“InProc”模式在会话中存储数据非常不稳定，并且每当 web.config 更改或任何其他因素（包括回收应用程序池）时都会重置。
然而，我的数据一次只停留几秒钟（时间是可变的，但实际上一点也不长），然后就消失了。我处于共享托管环境中，所以我不知道这是否与此有关。
知道发生了什么事吗？如果我将其作为 cookie 直接存储在客户端上会更好吗？请帮忙。
谢谢！
I just noticed this about a week ago. I'm storing data about the current puzzle a user is playing (www.wikipediamaze.com) like this:
HttpContext.Current.Session.Add("puzzleInfo", currentPuzzleInfo);
I know that storing data in the session using the "InProc" mode is very volatile and will get reset whenever the web.config changes or any number of other factors including recycling the app pool.
However my data is only staying for a few seconds at a time (the time is variable but literally not long at all) and then disappearing. I'm in a shared hosted environment so I don't know if that would have anything to do with it.
Any idea what's going on? Would I be better off just storing it directly on the client as a cookie? Please help.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
故障排除
每隔几秒丢失数据是不寻常的，您的共享托管提供商可能存在问题 - 听起来服务器由于某种原因不断丢弃会话。您可以显示 sessionID (Session.SessionID) 并查看它是否发生变化。
服务器上的其他人可能会导致进程崩溃。下面是一篇关于解决此类问题的 msdn 博客文章（向下滚动大约 25%）：http://blogs.msdn.com/webtopics/archive/2009/07/22/in-proc-session-state-management.aspx
在共享托管环境中，这对您没有太大帮助，但您可以将其传递给支持链。也许他们可以查看事件日志并确定谁破坏了 IIS，然后引导他们。
正如肖恩·麦克唐纳所说：
状态持久性的替代方案
无论如何，我总是发现 InProc 即使在专用服务器上也会间歇性地不可靠，因此我避免使用它。
请谨慎对待 Cookie——Cookie 会随每个请求（图像、脚本等）一起传输，并且应保持在最低限度。您可能会想，“嗯，这个项目不需要扩展”，但是一旦您做出了项目范围的设计决策，即您将使用 cookie 来保存您的状态，那么您就会遭遇众所周知的挫伤。
我的意思是，您正在脱离最佳实践，并且可能会遇到一些丑陋的情况，就像我需要暂时保留 xml 文档一样。这在饼干中可不是一个好主意！
如果由于处于共享托管环境中而无法设置会话状态服务器（顺便说一句，这确实很简单），则可以查看 SqlSessionStateStore，它可以让您将会话数据存储在 SQL Server 中。
Troubleshooting
Losing data every few seconds is unusual, there could possibly be a problem with your shared hosting provider -- sounds like the server is constantly dropping sessions for some reason. You could display the sessionID (Session.SessionID) and see if it changes.
There could be a process crash going on, caused by someone else on the server. Here's an msdn blog post on troubleshooting this type of problem (scroll down about 25% of the way through): http://blogs.msdn.com/webtopics/archive/2009/07/22/in-proc-session-state-management.aspx
This won't be much help to you in a shared hosting environment, but you could pass it up the support chain. Maybe they could look at the event logs and determine who is breaking IIS and give them the boot.
As stated by Sean McDonough:
Alternatives for State Persistance
At any rate, I have always found InProc to be intermittently unreliable even on dedicated servers, and so I avoid it.
Be cautious with cookies -- cookies get transmitted along with each request (images, scripts, etc) and should be kept down to the bare minimum. You may think, "Meh, this project doesn't need to scale," but once you make the project-wide design decision that you're going to use cookies to persist your state, you are cruising for a proverbial bruising.
And by that I mean, you are stepping out of best practices and may run into some ugly situations, like that time I needed to persist an xml document for a second. That would not be a good idea in a cookie!
If you don't have a way to set up session state server (which is really easy by the way) because you're in a shared hosting environment, you could look into SqlSessionStateStore, which lets you store your session data in a SQL Server.
布莱恩的建议非常好，我非常同意他的观点。我还想提供另一种可能性。
您对应用程序的托管环境了解很多吗？我询问的原因如下：鉴于您处于共享托管环境中，很有可能有多个 Web 服务器托管您的网站。如果多个服务器正在为您的站点提供服务，并且正在使用的负载平衡机制不保持任何类型的会话亲和性，那么您可能只是跳至不同的 Web 服务器并启动新会话；毕竟，进程内会话不会跟随您穿过盒子。
值得深思:-)
Brian's suggestions are excellent, and I couldn't agree more with the points he makes. I'd also like to offer one additional possibility.
Do you know much about the environment in which your application is being hosted? I ask for the following reason: given that you're in a shared hosting environment, there's a decent chance that there is more than one web server hosting your site. If multiple servers are serving up your site and a load balancing mechanism is in-use that doesn't maintain any sort of session affinity, you could simply be bouncing to a different web server and starting a new session; after all, in-proc session is not going to follow you across boxes.
Food for thought :-)