据我所知，当w3wp所有者进程回收时，所有InProc会话数据总是消失，因为它只驻留在w3wp内存中。
我想知道是否可以在进程外部某处进行回收时缓存会话数据，然后在重新启动时重新注入（并重建）会话。这样我就可以在必要时获得InProc的速度和状态服务器外化的可靠性。这可能吗？
答案 0 :(得分：2)
不，这是不可能的。没有用于“预热”进程内会话状态或缓存的API。无论如何，这样的解决方案将是不可靠的。你不能保证你的应用程序做的最后一件事就是导出它当前的会话状态，所以你永远不能指望导入的数据是最新的。
您可以在与Web应用程序相同的主机上使用进程外状态服务器。然后，Web应用程序可以自由回收，保持状态信息不变。这比使用SQL Server管理会话要快得多，因为您不必处理SQL或网络传输到另一台机器的开销，唯一的方法是它比进程内会话状态更糟糕的是数据必须跨越流程边界进行编组，但只要您没有大量快速变化的会话数据，这根本就不会引人注意。
还有其他替代方案，例如Microsoft Project Code Named "Velocity"或ScaleOut Software's SessionServer（我敢肯定）提供分布式缓存机制，可以在服务器场中的服务器之间保持会话状态或缓存同步不得不求助于使用SQL Server。
与其他用户发布的内容相反，如果可能的话，我不会使用ViewState来存储会话数据。首先，它不是真正的会话状态，如果用户向后或向前移动它可能会丢失。其次，这是相当不安全的。第三，如果滥用，会导致大量页面膨胀。
答案 1 :(得分：0)
也许您可以在cookie（或ViewState）中存储足够的信息，以便在工作进程被回收的情况下，您可以根据该数据重新创建会话。
或者您可以创建自己的状态服务器（例如Windows服务），在其中存储部分会话，并通过远程处理或类似方式从Web应用程序访问此服务。
答案 2 :(得分：0)
如果这是您的意图，您应该使用SQL Server进行会话状态。您想要的是可以从主机进程的完整结束中恢复的会话。 inproc或stateserver都不支持它们一旦失效就会丢失所有数据。你可以编写自己的状态方法，但这样做很费力。如果你想这样做，请点击这里：
您可能想做的不是使用会话，而是更多地依赖ViewState。如果您拥有高流量站点，这是将工作负载推送到客户端的好方法。