当 webroot 更改时防止会话结束
我们的 Intranet 有一个自定义的会员资格系统（不是 asp 会员资格），它将值放入会话信息中以识别用户。由于内联网不断发展，我经常需要每天多次向实时服务器发布更改。每次我这样做时，登录的用户的会话都会结束，他们必须重新登录。这会导致各种问题，我不会在这里让任何人感到厌烦。
我的问题是——有什么办法可以防止这种情况发生，还是我只能忍受它？花了近3个小时的时间，没有找到任何解决方案。
提前致谢。
Our intranet has a custom membership system (not asp membership) which puts values in the session information to identify users. As the intranet is constantly evolving, I often have to publish changes to the live server several times every day. Each time I do, the users who are logged in's sessions end and they have to log in again. This causes various issues which I won't bore anybody with here.
My question - is there anyway to prevent this, or do I just have to live with it? Have spent the last 3 hours Goggling and can find no solution.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
解决方案是使用不同的会话模式；您正在使用“InProc”，这意味着会话与您的应用程序存储在同一应用程序空间中。您可以使用“StateServer”或“SQLServer”，但是这些可能需要更改应用程序（以及额外的设置；StateServer 将需要在 IIS Server 上运行单独的服务，而 SQLServer 将需要一个数据库来存储信息）。您存储在会话中的所有内容都需要可序列化。
以下是 MSDN 上有关会话模式的信息。
The solution is to use a different Session Mode; You are using "InProc", which means the session is stored in the same application space as your application. You can use "StateServer" or "SQLServer", however these will likely require application changes (and additional setup; StateServer will require a separate service to be running on the IIS Server and SQLServer will require a database to store information in). Everything that you store in the Session will need to be serializable.
Here is the information on MSDN regarding Session Mode.
您应该尝试Sql Server 会话状态存储
You should try Sql Server session state storage
如果您的问题是如何保持服务器 24x7 运行而不会对用户造成任何干扰（会话丢失/系统停机等），那么它涉及以下步骤：
[4.1.] 更改负载均衡器配置，使其不将请求路由到 S1。
[4.2.] 将应用程序部署到 S1
[4.3.] 更改负载均衡器配置，这次包含 S1 并排除 S2。 （这样，所有后续请求都应命中 S1，从 S1 和 S2 连接的公共数据库获取会话信息）
[4.4.] 根据需要重复上述步骤。
最重要的是，首先在现场/生产环境中执行上述步骤之前，请尝试始终在临时环境中测试上述步骤。
祝你好运！
If your question is about keeping your server up 24x7 without causing any disruption to users (loss of session/ system downtime, etc), then it involves the following steps:
[4.1.] Change your load balancer configuration for it to not route requests to S1.
[4.2.] Deploy the apps to S1
[4.3.] Change your load balancer configuration for it include S1 and exclude S2 this time. (With this all subsequent requests shall hit S1 getting the session info. from the common DB where S1 and S2 are connected)
[4.4.] Repeat the above steps as required.
Most important of all try to always test the above steps in your staging environment before doing it first on live/production boxes.
Good luck!