几点Session使用的经验(sessionId)(转载)
问:当页面中是否了frameset,发现在每个frame中显示页面的SessionID在第一次请求时都不相同,为什么?
答:原因是你的frameset是放在一个htm页面上而不是ASPX页面。
在一般情况下,如果frameset是aspx页面,当你请求页面时,它首先将请求发送到Web服务器,此时已经获得了SessionID,接着浏览器会分别请求Frame中的其他页面,这样所有页面的SessionID就是一样的,就是FrameSet页面的SessionID。
然而如果你使用Html页面做FrameSet页面,第一个请求将是HTML页面,当该页面从服务器上返回是并没有任何Session产生,接着浏览器会请求Frame里面的页面,这样这些页面都会产生自己的SessionID,所以在这种情况下就会出现这种问题。当你重新刷新页面时,SessionID就会一样,并且是最后一个请求页面的SessionID。
问:是否可以将不同应用程序的Session保存在相同的SQL Server服务器的不同数据库上。
答:可以,请参考:
FIX: Using one SQL database for all applications for SQL Server session state may cause a bottleneck
http://support.microsoft.com/default.aspx?scid=kb;en-us;836680
问:在Session_End是我是否可以获得有效的HttpSessionState和HttpContext对象?
答:你可以在这个方法中获得HttpSessionState对象,可以直接使用Session来访问即可。但是不能获得HttpContext对象,因为该事件并没有和任何请求相关联,因此不存在上下文对象。
问:当我设置EnableSessionState为“ReadOnly”后,但是我在InProc模式下依然可以修改Session的值,这是为什么?
答:即使EnableSessionState标示为ReadOnly,但是在InProc模式下用户依然可以编辑Session。唯一不同的是,在请求过程中Session将不会被锁住。
问:当Session设置成cookieless后会有什么影响?
答:当把cookieless设置成true时,主要会有下面的约束:
1、在页面中不能使用绝对链接
2、在应用程序中在除了Http和Https之间的切换时需要完成一些其他的步骤。
如果发送一个链接给其他人,此时的URL里面将包含Session ID的信息,所以两个人将公用一个Session。
问:为了可以顺序访问Session的状态值,Session是否提供了锁定机制?
答:Session实现了Reader/Writer的锁机制:
当页面对Session具有可写功能(即页面有<%@ Page EnableSessionState="True" %>标记),此时直到请求完成该页面的Session持有一个写锁定。
当页面对Session具有只读功能(即页面有<%@ Page EnableSessionState="ReadOnly" %>标记),此时知道请求完成该页面的Session持有一个读锁定。
读锁定将阻塞一个写锁定;读锁定不会阻塞读锁定;写锁定将阻塞所有的读写锁定。这就是为什么两个框架中的同一个页面都去写同一个Session时,其中一个要等待另一个(稍快的那个)完成后,才开始写。
问:如果使用了cookieless,我该如何从HTTP页面定向到HTTPS?
答:请尝试下面的方法:
String originalUrl = "/fxtest3/sub/foo2.aspx";
String modifiedUrl = "https://localhost" + Response.ApplyAppPathModifier(originalUrl);
Response.Redirect(modifiedUrl);
问:什么类型的对象可以保存在Session里?
答:这依赖使用的Session的模式,当使用的是进程内(InProc)的Session那么可以轻松的保存任何对象。如果你使用了非InProc的模式,则只能保存可以序列化和反序列化的对象,如果此时保存的对象不支持序列化,则不能保存到这种模式(非InProc)的Session里。
问:为什么每次请求的SessionID都不相同?
答:该问题可能是没有在Session里面保存任何信息引起的,即程序中任何地方都没有使用Session。当Session中保存信息之后SessionID将一直和浏览器相关,此时的SessionID将不会在变化。