当 W3WP (IIS) 进程回收时保留 ASP.NET InProc 会话
据我了解，当其 w3wp 所有者进程回收时，所有 InProc 会话数据总是消失，因为它仅驻留在 w3wp 内存中。
我想知道当回收发生在进程外部的某个地方时是否可以缓存会话数据，然后在会话恢复时重新注入（并重建）会话。这样我就可以在必要时获得 InProc 的速度和类似状态服务器的外部化的可靠性。这可能吗？
I understand that all InProc session data is always gone when its w3wp owner process recycles as it only resides in the w3wp memory.
I wondered though if it is possible to cache the session data when recycling happens somewhere external to the process, and then reinject (and rebuild) the session when it comes back up. That way I'd get the speed of InProc with the reliability of state server-like externalization when necessary. Is this possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不，这是不可能的。没有 API 可以“预热”进程内会话状态或缓存。这样的解决方案无论如何都是不可靠的。您无法保证应用程序所做的最后一件事是导出其当前会话状态，因此您永远不能指望导入的数据是最新的。
您可以在与 Web 应用程序相同的主机上使用进程外状态服务器。然后 Web 应用程序可以自由回收，保持状态信息完整。这比使用 SQL Server 管理会话快得多，因为您不必处理 SQL 或网络传输到另一台计算机的开销，它比进程内会话状态更糟糕的唯一方式是数据必须跨进程边界封送，但只要您没有大量快速变化的会话数据，这根本就不应该被注意到。
还有其他替代方案，例如名为“Velocity”的 Microsoft Project Code 或 ScaleOut Software 的 SessionServer （我确信还有其他）提供分布式缓存机制可以使服务器场中的服务器之间的会话状态或缓存保持同步，而无需求助于使用 SQL Server。
与其他用户发布的内容相反，如果可能的话，我不会使用 ViewState 来存储会话数据。其一，这不是真正的会话状态，如果用户向后或向前移动，它可能会丢失。其次，它相当不安全。第三，如果滥用，它会导致大量页面膨胀。
No, this isn't possible. There is no API to "warm up" in-process session state or cache. Such a solution would be unreliable anyway. You couldn't gaurantee that the last thing your app did would be to export its current session state, so you could never count on the imported data to be current anyway.
You can use the out-of-proc state server on the same host as your web application. Then the web application can recycle freely, keeping the state information intact. This is quite a bit faster than using SQL Server to manage sessions, as you don't have to deal with the overhead of SQL or network transit to another machine, the only way it's worse than in-process session state is that data has to marshal across process boundaries, but as long as you don't have a massive amount of rapidly changing session data, this shouldn't be noticeable at all.
There are also other alternatives, such as Microsoft Project Code Named "Velocity" or ScaleOut Software's SessionServer (among others I'm sure) that offer distributed caching mechanisms that can keep session state or cache synchronized between servers in a server farm without having to resort to using SQL Server.
Contrary to what another user posted, I would NOT use ViewState to store session data if at all possible. For one, it's not true session state, if a user moves back or forward it can be lost. Second, it's fairly insecure. Third, it causes massive page bloat if abused.
也许您可以在 cookie（或 ViewState）中存储足够的信息，以便在工作进程被回收时可以根据该数据重新创建会话。
或者，您可以创建自己的状态服务器（例如 Windows 服务），在其中存储部分会话，并通过远程处理或类似方式从 Web 应用程序访问此服务。
Maybe you can store enough information in a cookie (or in ViewState) so that you can re-create a session based on that data in the case the worker process was recycled.
Or you could create your own state server (e.g. a windows service) where you store part of your session, and access this service from the web app via remoting or similar.
如果您愿意的话，您应该使用 SQL Server 来获取会话状态。您想要的是可以从主机进程完全结束中恢复的会话。 inproc 或 stateserver 都不支持这一点，因为一旦它们宕机，它们就会丢失所有数据。您可以编写自己的状态方法，但这会很费力。如果您想这样做，请按照以下说明：
http://www.exforsys.com/tutorials/asp.net-2.0/asp.net-2.0-customizing-the-session-state-mechanism.html
您可能想要什么要做的就是根本不使用session，而是更多地依赖ViewState。如果您的网站流量较高，那么这是将工作量转移给客户的好方法。
You should use the SQL Server for Session State if that's your intention. What you want are sessions that can recover from a complete ending of the host processs. Neither inproc or stateserver support that as once they go down they lose all data. You could write your own state method, but that would be laboriuous. Here's directions if you want to do that:
http://www.exforsys.com/tutorials/asp.net-2.0/asp.net-2.0-customizing-the-session-state-mechanism.html
What you may want to do is not use sessions at all, but rather rely more on ViewState. If you have a high traffic site that's a good way to push the workload off to clients.