Asp.net 会话数据丢失
我在上一个问题中谈到过这一点，但后来我缩小了问题范围，以便能够得到回答。首先，一些背景知识。
我有一个 ASP.net 网站，可以在本地服务器上正常运行，但是当它在实时服务器上并从外部访问时，它会出现一些会话数据问题，偶尔会引发错误。第一个问题是IE9的问题。会话变量在到达第二页并命中存储过程后就不会持续存在。我通过让页面在 IE7 模式下运行来解决这个问题 -
这在某些浏览器上仍然会发生（特别是在 firefox 中会发生一次），但我创建了一个循环，当会话变量为空时，强制它返回菜单页面，因此它只是显示为页面未加载，并且可以再次按下“打开”按钮。
但是，当我尝试将数据保存在表单上时，出现了新问题。它将一些会话变量传递到存储过程接口（如员工 ID 等），并且似乎发生了超时。然而，在 webconfig 和 IIS 中设置的所有会话超时都非常高（很多小时），并且工作进程设置为永不过期或回收。而且，即使在一两分钟后也会发生这种情况，因此不可能是超时。就像它随机丢失会话值一样。奇怪的是，如果您返回并再次保存 - 使用相同的数据执行相同的操作 - 它往往会起作用。有时需要进行几次迭代，但最终它会起作用。
奇怪的是，它往往会随机丢失视图状态的某些部分 - 例如字段值 - 但这可能是不相关的，并且与加载时自动填充的字段有更多关系。但我想我应该把它包括在内，以防万一它提供了关于为什么它可能这样做的信息。
我正在考虑一种解决方法，方法是在页面加载后立即将会话变量转储到视图状态变量中，但我真的很想直接解决问题，这样我就不必在将来可以处理它的时候了。不要做那样的事情。 IIS 的某些部分（顺便说一下，是 IIS 6）是否可能是罪魁祸首？会话变量在被频繁使用时是否会死亡？我不能说我对服务器设置了解很多，但我从这种情况中学到了很多东西，并且击败它对于我的士气来说是一个伟大的胜利。感谢您的阅读，抱歉这么久！
I spoke about this in a previous question, but I have since narrowed down the issue to make it possible to be answered. First, some background.
I have an ASP.net website that functions normally on the local server, but when it's on the live server and accessed externally, it has some session data issues that make occasionally throw errors. The first issue turned out to be an problem with IE9. The session variable just wouldn't persist after it reached the second page and hit the stored procedure. I fixed this by foring the page to run in IE7 mode with -
This still occurs on some browsers (specifically it occurs -once- with firefox) but I created a loop that forces it back to the menu page when the session variable is blank so it just appears as the page didn't load and the "open" button can be pressed again.
However, the new problem happens when I attempt to save the data on a form. It passes a few session variables in to the stored procedure interface (like staff ID and such) and what appears to happen is that it times out. However, all of the timeouts for the session set in webconfig and IIS are extremely high numbers (many hours) and the worker processes are set to never expire or recycle. Also, it happens even after a minute or two so it can't be the timeout hitting. It's just like it randomly loses the session values. The weird thing is that if you go back and save again - performing the same actions with the same data - it tends to work. Sometimes it takes a few iterations of this but ultimately it will work.
The strange thing is also that it tends to randomly lose pieces of the viewstate - such as field values - but that might be unrelated and have more to do with the fields that are filled automatically at load. But I thought I'd include that in case it offers and information as to why it might be doing this.
I'm considering a workaround by dumping the session variables in to viewstate variables as soon as the page loads, but I'd really like to address the problem directly so I don't have to deal with it in the future when I can't do something like that. Is there some poriton of IIS (It is IIS 6 by the way) that could be the culprit? Are session variables just known for dying when being thrown around a lot? I can't say I know a great deal about server set up but I've learned a lot from this situation and beating this will be a wonderful victory for my morale. Thank you for reading and sorry it' so long!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
请检查该服务器是否负载平衡。
无论哪种情况，请查看本文。 http://aspalliance.com/1182_Troubleshooting_Session_Related_Issues_in_ASPNET
希望这会有所帮助。
Please check if this server is load balanced.
In either case, check this article out. http://aspalliance.com/1182_Troubleshooting_Session_Related_Issues_in_ASPNET
Hope this helps.
好的！
阅读您的帖子并思考后，我认为问题最有可能的原因是狡猾的 ISA 服务器。代理往往会弄乱 HTTP 内容，决定更改标头等。正如您所提到的，只有在外部访问时才会发生这种情况。这是处于中间问题的人的标志。
现在为了证明，您必须比较外部发送的标头和您收到的标头。这有点困难，但也不是不可能。您所需要做的就是在服务器端记录所有标头（请求），同时从客户端计算机（可能使用 fiddler）执行相同操作。
这应该能够证明狡猾的代理——我们公司也有类似的问题。
OK!
After reading your post and thinking about it, I think most likely cause of the problem is the dodgy ISA Server. Proxies tend to mess around with the HTTP content, decide to change the headers and the like. As you have mentioned, this only happens if it is accessed externally. This is the hallmark of man in the middle issues.
Now to prove, you have to compare the headers sent externally and headers you receive. This is a bit difficult but not impossible at all. All you need is to log all the headers (requests) on the server side while you do the same from the client's machine (perhaps using fiddler).
This should be able to prove the dodgy proxy - we have a similar issue in our company.
好吧，我做了几件事，现在可以正常工作了，但我没有测试哪一个是实际的解决方案，据我所知，它们中没有一个能够真正解决问题。首先，在某些时候，我将可用的工作进程从一个增加到三个，我认为这意味着允许用户在必要时在服务器上运行多个进程，但事实证明这只是服务器场所必需的。所以我把它设置回一。以前发生过这个问题，我基本上只是在尝试看看有什么办法可以解决它。
我做的第二件事是在一个私有子中添加一个简单的 if 语句（如果会话变量为空），其中包含发送会话变量的存储过程的接口。我认为这将是一个解决方法，但后来我查看了旧的错误日志，甚至不是存储过程接口引发了错误。我根本不知道为什么它会解决这个问题。
我还设置了一些 PerfLogs，就像 Rahul 链接我的那个页面一样，以尝试监视会话中发生的情况。
现在，除了这些尝试中的一些事情（以及我所做的其他小事情）实际上解决了问题之外，还有一个事实是，它从一开始就从未在本地发生过。我不太确定发生了什么，但它现在正在发挥作用，我不会再深入研究它，因为我有很多项目需要处理。在我看来，这很可能是 ISA 服务器将来可能出现的问题，但我对其设置缺乏了解，这限制了我真正进入那里并自行查找。当我询问时，我被告知它应该允许我通过它发送所需的所有内容。无论如何，我很高兴能够继续前进并让这项工作正常进行。希望所有这些对遇到类似情况的人有所帮助！感谢大家的帮助！
Well I did a couple things and it is working now, but I didn't test which was the actual solution and none of them, the best of my understanding, should have actually fixed the issue. First of all, at some point I increased the available worker processes to three from one, which I thought would mean would allow the user to run multiple processes on the server if necessary, but it turns out that is only necessary for server farms. So I set that back to one. It was one before when this issue was occuring and I was basically just expirmenting to see what would fix it.
The second thing I did was add in a simple if statement (if the session variable is blank) in one private sub that contains an the interface for a stored procedure that sends a session variable. I thought this would be a workaround, but then I looked at my old error logs and it wasn't even the stored procedure interface that was throwing the error. I have no idea why it would have fixed the issue at all.
I also set up some PerfLogs like on that page that Rahul linked me to to try and monitor what's going on with the sessions.
Now aside from the odd fact that something in there amongst those attempts (along with whatever other minor things I did) actually fixed the problem, there's the fact that it was never happening locally to begin with. I'm not really sure what happened, but it's working now and I'm not going to dig too deep in to it again since I have a lot of projects to attend to. In my opinion it's most likely an issue with the ISA servers that may arise in the future, but my lack of knowledge about their settings limited me from really getting in there and looking around for myself. When I asked about it, I was told that it should allow for everything I need to send through it to go through it. Regardless, I'm just happy to be able to move on and get this working. Hope all of this helps some people in a similar situation! Thanks for all of the help everyone!
这次我实际上找到了真正的解决方案。它仍然没有多大意义，但我想我应该把它带到这里供大家查看。事实证明，从表中提取的日期之一被存储在会话变量中作为空白（即使它不应该是），然后以某种方式，即使有一个 if 语句应该阻止它尝试将会话的空白字符串转换为日期。当然很奇怪。就好像会话在到达 if 语句时有一个值，然后在根据条件检查它后，将其更改为空白字符串并引发错误。
所以事实证明这并不是真正的会话问题，只是一个奇怪的日期问题。这种情况只发生在一个人和桌子上的一个特定日期之间。我通过简单地在它周围放置一个 try-catch 来修复它。从那时起，这个人的一切都运转良好。再次感谢大家的帮助！
I actually found the real solution this time around. It still doesn't make a lot of sense but I thought I'd bring it here just for everyone to see. It turns out, one of the dates that was being pulled from a table was being stored in the session variable as a blank (even though it shouldn't have been) and then somehow, even though there was an if statement that should have prevented it, it tried to convert the blank string of the session to a date. Certainly strange. It was as if the session had a value when reaching the if statement and then after it checked it against the criteria, it changed it to a blank string and threw the error.
So it turns out it wasn't really a session issue, just a strange date issue. It was only occuring with one person and one particular date from the table. I fixed it by simply putting a try-catch around it. Everything has been working fine for that individual since then. Thanks again for the help everyone!