問：當頁面中是否了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將不會在變化。
