Session使用的經驗

問：當頁面中是否了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

問：在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具有可寫功能（即頁面有標記），此時直到請求完成該頁面的Session持有一個寫鎖定。
當頁面對Session具有隻讀功能（即頁面有標記），此時知道請求完成該頁面的Session持有一個讀鎖定。
讀鎖定將阻塞一個寫鎖定；讀鎖定不會阻塞讀鎖定；寫鎖定將阻塞所有的讀寫鎖定。這就是為什麼兩個框架中的同一個頁面都去寫同一個Session時，其中一個要等待另一個（稍快的那個）完成後，才開始寫。

問：如果使用了cookieless，我該如何從HTTP頁面定向到HTTPS？
答：請嘗試下面的方法：
String originalUrl = "/fxtest3/sub/foo2.aspx";
String modifiedUrl = "" + Response.ApplyAppPathModifier(originalUrl);
Response.Redirect(modifiedUrl);

問：什麼型別的物件可以儲存在Session裡？
答：這依賴使用的Session的模式，當使用的是程式內（InProc）的Session那麼可以輕鬆的儲存任何物件。如果你使用了非InProc的模式，則只能儲存可以序列化和反序列化的物件，如果此時儲存的物件不支援序列化，則不能儲存到這種模式（非InProc）的Session裡。

問：為什麼每次請求的SessionID都不相同？
答：該問題可能是沒有在Session裡面儲存任何資訊引起的，即程式中任何地方都沒有使用Session。當Session中儲存資訊之後SessionID將一直和瀏覽器相關，此時的SessionID將不會在變化。