Session使用问题小结

现象一：在一个网站中，当访问一个处理比较耗时的页面（A页面），页面请求还没有返回时，此时再点击访问该网站的其他页面（B页面）会出现B页面很久都没有响应和返回，直到A页面输出返回数据时才开始处理B页面的请求，造成请求排队处理，A页面阻塞了B页面的请求处理。

原因：Session实现了Reader/Writer的锁机制

       当页面对Session具有可写功能（即页面有<%@ Page EnableSessionState="True" %>标记），此时直到请求完成该页面的Session持有一个写锁定。当页面对Session具有只读功能（即页面有<%@ Page EnableSessionState="ReadOnly" %>标记），此时知道请求完成该页面的Session持有一个读锁定。读锁定将阻塞一个写锁定；读锁定不会阻塞读锁定；写锁定将阻塞所有的读写锁定。这就是为什么两个框架中的同一个页面都去写同一个Session时，其中一个要等待另一个（稍快的那个）完成后，才开始写。

 

现象二：为什么有时候每次请求的SessionID都不相同
原因：该问题可能是没有在Session里面保存任何信息引起的，即程序中任何地方都没有使用Session。当Session中保存信息之后SessionID将一直和浏览器相关，此时的SessionID将不会在变化。

 

现象三：当设置EnableSessionState为“ReadOnly”后，但是我在InProc模式下依然可以修改Session的值
原因：即使EnableSessionState标示为ReadOnly，但是在InProc模式下用户依然可以编辑Session。唯一不同的是，在请求过程中Session将不会被锁住。 
 

待续......