在ASP.NET的开发中,总遇到Session丢失.最常见的情况是当用户登录后将用户信息保存在Session中例如Session["user"]=user;在其后的页面中检查Session["user"]是否为空,如果为空则要求用户重新登录,我们遇到的问题是在用户登录后的1小段时间后(也许只有5分钟),Session["user"]就已经丢失了,Session["user"]!=null的判断就不成立了.
遇到这样的问题我们首先想到的可能是session过期了,需要设置web.config中session的过期时间,最常见的简单设置就是:
<sessionState mode="InProc" timeout="20" />这里的timeout是指的session的过期时间单位是分钟,但是通常这样的设置还不能解决你的问题,因为session的默认过期时间就是20分钟.
现在我们来看看session在web.config中的配置,完整的配置如下:
< sessionState mode ="Off|InProc|StateServer|SQLServer" 
cookieless ="true|false" timeout ="number of minutes" stateConnectionString ="tcpip=server:port" sqlConnectionString ="sql connection string" stateNetworkTimeout ="number of seconds" />
其实我也很少使用上面这样完全的配置,但是了解这样配置的用法是我们解决session过期的方法之一,下面我们来看看这段配置的说明,下面这段文字来源于网络,为了方便大家的查看将其拷贝过来了.
mode属性 设置将Session信息存储到哪里
Off 设置为不使用Session功能
InProc 设置为将Session存储在进程内，就是ASP中的存储方式，服务器将Session信息存储在IIS进程中,这是默认值。
StateServer 设置为将Session存储在独立的状态服务中。
SQLServer 设置将Session存储在SQL Server中。
cookieless属性 设置客户端的Session信息存储到哪里
ture 使用Cookieless模式
false 使用Cookie模式，这是默认值。
timeout属性 设置经过多少分钟后服务器自动放弃Session信息。默认为20分钟 ,也就是我们通常说的过期时间.
stateConnectionString属性 设置将Session信息存储在状态服务中时使用的服务器名称和端口号，例如："tcpip=127.0.0.1:42424”。当mode的值是StateServer是，这个属性是必需的。
sqlConnectionString属性 设置与SQL Server连接时的连接字符串。例如"data source=localhost;Integrated Security=SSPI;Initial Catalog=northwind"。当mod e的值是SQLServer时，这个属性是必需的 。
stateNetworkTimeout属性 设置当使用StateServer模式存储Session状态时，经过多少秒空闲后，断开Web服务器与存储状态信息的服务器的TCP/IP连接的。默认值是10秒钟。
第二个解决此问题的方法就是,不使用Inproc模式保存session而改用StateServer模式保存.
<sessionState mode= "StateServer" stateConnectionString= "tcpip=127.0.0.1:42424" cookieless= "false" timeout= "120" />
使用上面的配置需要关注下面的几个问题:
1、要在服务中开启“ASP.Net State Service”服务（设为“自动”）
2、如果stateConnectionString的值不是127.0.0.1或者localhost等代表本地地址的值，需要修改注册 表：HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/aspnet_state /Parameters 节点 → 将 AllowRemoteConnection 的键值设置成“1”（1 为允许远程电脑的连接，0 代表禁止）→ 设置 Port (端口号)
3、session中存储非序列化的对象，如果违反会抛出 无法序列化会话状态。在 “StateServer”或“SQLServer”模式下，ASP.NET 将序列化会话状态对象，因此不允许使用无法序列化的对象或 MarshalByRef 对象。如果自定义会话状态存储在“Custom”模式下执行了类似的序列化，则适用同样的限制。 这样的异常。如果向session存储自定义的对象，那么该对象的类上一定要加上[Serializable]注释,在本例中需要将user的类型标注为可序列化。
下面我们来看看Inproc模式和StateServer模式的优缺点:
InProc模式
优点：获取session状态的速度快，session状态直接存储在iis的进程中。
缺点：易丢失，经常需要重新登录,实际上在几个项目中我也遇到了这个问题.
StateServer模式
优点：session状态单独存储在一个进程中，不会因为iis或者应用的重启而丢失状态
缺点：获取session状态的速度比InProc慢一些，毕竟是两个不同的进程。
也许你想找出session在什么地方弄丢的,那么你可以尝试下面的操作:
你还记得ASP.NET中有个global.asax文件吗?里面有两个关于session的两个事件
Session_Start ：在一个新用户访问应用程序 Web 站点时，该事件被触发。
Session_End ：在一个用户的会话超时、结束或他们离开应用程序 Web 站点时，该事件被触发。
你可以在这两个事件中记录session的相关操作,记录当前的session值,当前时间,操作session的页面等等,也许对你找到错误会有所帮助.
