ASP.NET 支持三种会话状态模式：
InProc：In-Proc 模式将值存储在 ASP.NET 辅助进程的内存中。因此，该模式提供了对这些值的最快访问。但是，当 ASP.NET 辅助进程被回收时，状态数据便会丢失。
StateServer：与上一模式不同，StateServer 模式使用独立的 Microsoft Windows 服务来存储会话变量。因为该服务独立于 Microsoft Internet Information Server (IIS)，所以它可以在另一独立的服务器上运行。您可以将此模式用于负载平衡解决方案，因为多个 Web 服务器可共享会话变量。尽管在重新启动 IIS 时会话变量不会丢失，但在跨越进程边界时，性能会受到影响。
SqlServer：如果会话信息的持久性对于您很重要，那么您可以使用 SqlServer 模式，以便利用 Microsoft SQL Server 来确保达到最高级别的可靠性。SqlServer 模式类似于进程外模式，只是前者的会话数据维护在 SQL Server 中。SqlServer 模式还让您能够利用位于 IIS 进程外的一个状态存储区，该状态存储区既可位于本地计算机上，也可位于远程服务器上。
网站的默认Session状态模式应该是InProc，限制了本系统网站使用。StateServer和SqlServer都作为扩展，将会话信息存储在IIS进程之外，实现了不同Web服务器之间的共享。当然，这两种模式都需要做相应的配置和消耗一定的性能，我们暂且不说这一点。仔细研究发现，这两种扩展模式主要面向的是网站的分流和负载均衡，共享Session的网站之间的结合是非常非常密切的，并且ASP.NET将所有的实现都进行了封装，我们无法获取和记录每一次共享的细节。这并不适合我们最开始的需求。
假设：A系统通过Session保存了一个User实例，那么如果B系统需要使用这个Session，则必需拥有A系统中User的细节。如果A、B两个系统是完全不同，甚至其中不同细节User类，更甚至A、B系统中都不只一处功能使用到Session，Session的命名又总碰巧一致。呵呵，那一切将变得不可思议。当然，如果我A、B为统一个系统的两个不同的应用层，那StateServer和SqlServer这两种方式将能够很好的满足需求。至于要满足我们上面的需求，只能是另外想办法了。
寻找解决办法，我们比较关系用户体验，那么先从用户的使用流程开始.......
