System.Web 命名空间提供使得可以进行浏览器与服务器通讯的类和接口。此命名空间包括提供有关当前 HTTP 请求的广泛信息的 HttpRequest 类、管理对客户端的 HTTP 输出的 HttpResponse 类以及提供对服务器端实用工具与进程的访问的 HttpServerUtility 类。System.Web 还包括用于 Cookie 操作、文件传输、异常信息和输出缓存控制的类。
System.Web.SessionState 命名空间提供可将特定于某个单个客户端的数据存储在服务器上的一个 Web 应用程序中的类和接口。会话状态数据用于向客户端提供与该应用程序保持持久连接的样式。状态信息可以存储在本地进程内存中，或者，对于网络场配置，也可以使用 ASP.NET 状态服务或 SQL Server 数据库将其存储在进程之外。会话状态可以与不支持 Cookie 的客户端一起使用。ASP.NET 可以配置为对客户端和服务器之间传输的 URL 字符串中的会话 ID 进行编码。
System.Web.SessionState.HttpSessionState 我们使用的Session实际上就是这个类的对象。Session在使用它后的第一次请求的时候被创建，这个可以通过Session.IsNewSession的值来进行判断。public sealed class HttpSessionState : ICollection, IEnumerable 从这个声明可以看出，HttpSessionState继承自ICollection接口，说明以后的Session["xxx"]都是Add进入到Session这个Collection中的。我们通过名字取得一个Session实际上使用了索引。
属性：
- IsCookieless: 获取一个值，该值指示会话 ID 是嵌入在 URL 中还是存储在 HTTP Cookie 中。如果会话嵌入在 URL 中，则为 true；否则，为 false。
- IsSynchronized:标识一个Session是不是同步的（线程安全），鉴于超级严重的多窗口操作Session互相覆盖问题，默认的Session.IsSynchronized的返回值是False.
- Timeout: 设置Session超时的时间。以“分钟”为单位。
System.Web.SessionState 还具有一个枚举型变量，System.Web.SessionState.SessionStateMode，用于表示Session存在的4种状态：
- InProc, 默认方式，与aspnet_wp进程一起执行。
- off, Session值被禁用。
- SQLServer ,会话状态正在使用进程外 SQL Server 存储状态信息。
- StateServer, 会话状态正在使用进程外 Windows NT Server 存储状态信息。
以下是从网络上摘抄过来的有关Session的一些问题，原始链接是（http://www.hackchina.cn/Article/base/daima1/200601/9172.html）：
- 问：为什么当调用Session.Abandon时并没有激发Session_End方法？
答：首先Session_End方法只支持InProc（进程内的）类型的Session。其次要激发Session_End方法，必须存在Session（即系统中已经使用Session了），并且至少要完成一次请求（在这次请求中会调用该方法）。 - 问：为什么当我在InProc模式下使用Session会经常丢失？
答：该问题通常是由于应用程序被回收导致的，因为当使用进程内Session时，Session是保存在aspnet_wp进程中，当该进程被回收Session自然也就没有了，确定该进程是否被回收可以通过查看系统的事件查看器获得信息。
具体信息请参考：
Session variables are lost intermittently in ASP.NET applications
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q316148
在1.0的时候也有一个bug会导致工作进程被回收并重启，该bug已经在1.1和sp2中修复。
关于该bug的详细信息请参考：
ASP.NET Worker Process (Aspnet_wp.exe) Is Recycled Unexpectedly.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q321792 - 问：为什么当Session超时或者Abandoned后，新Session的ID和原来的相同？
答：因为SessionID是保存在客户端浏览器的实例里，当Session超时在服务器重新建立Session时，将使用浏览器传来的SessionID，所以当Session超时后，再重新建立后SessionID并不变。 - 问：什么类型的对象可以保存在Session里？
答：这依赖使用的Session的模式，当使用的是进程内（InProc）的Session那么可以轻松的保存任何对象。如果你使用了非InProc的模式，则只能保存可以序列化和反序列化的对象，如果此时保存的对象不支持序列化，则不能保存到这种模式（非InProc）的Session里。 - 问：为什么在Session_End中不能使用Response.Redirect和Server.Transfer方法跳转页面？
答：Session_End是一个在服务器内部激发的事件处理函数。它是基于一个服务器内部的计时器的，在激发该事件时服务器上并没有相关的HttpRequest对象，因此此时并不能使用Response.Redirect和Server.Transfer方法。 - 问：在Session_End中是否可以获得HttpContext对象？
答：不行，因为这个事件并没有和任何的请求（Request）相关联，没有基于请求的上下文 - 问：Session.Abandon和Session.Clear有何不同？
答：主要的不同之处在于当使用Session.Abandon时，会调用Session_End方法（InProc模式下）。当下一个请求到来时将激发Session_Start方法。而Session.Clear只是清除Session中的所有数据并不会中止该Session，因此也不会调用那些方法。 - 问：为了可以顺序访问Session的状态值，Session是否提供了锁定机制？
答：Session实现了Reader/Writer的锁机制：
当页面对Session具有可写功能（即页面有<%@ Page EnableSessionState="True" %>标记），此时直到请求完成该页面的Session持有一个写锁定。
当页面对Session具有只读功能（即页面有<%@ Page EnableSessionState="ReadOnly" %>标记），此时知道请求完成该页面的Session持有一个读锁定。
读锁定将阻塞一个写锁定；读锁定不会阻塞读锁定；写锁定将阻塞所有的读写锁定。这就是为什么两个框架中的同一个页面都去写同一个Session时，其中一个要等待另一个（稍快的那个）完成后，才开始写。 - 问：为什么当我设置cookieless为true是我在重定向的时候会丢失Session？
答：当使用cookieless时，你必须使用相对路径替换程序中的绝对路径，如果使用绝对路径ASP.NET将无法在URL中保存SessionID。
例如：将/myDir/mySubdir/default.aspx换成../default.aspx即可。 - 问：我在我自己的类中该如何使用Session呢？
答：可以使用HttpContext.Current.Session方式使用，具体方法如下：
HttpContext.Current.Session["SessionKey"] = "SessionValue";
类似的你还可以使用这种方式使用Application对象。
扫一扫
554
到【灌水乐园】发言
