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

NET技術：從別人那拷下來的幾點Session使用的經驗（轉載），轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。