问：当页面中是否了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
?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将不会在变化。