問:當頁面中是否了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
<a href="http://support.microsoft.com/default.aspx?scid=kb;en-us;836680">http://support.microsoft.com/default.aspx?scid=kb;en-us;836680</a>
問:在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";
Response.Redirect(modifiedUrl);
問:什麼類型的對象可以儲存在Session裡?
答:這依賴使用的Session的模式,當使用的是程序内(InProc)的Session那麼可以輕松的儲存任何對象。如果你使用了非InProc的模式,則隻能儲存可以序列化和反序列化的對象,如果此時儲存的對象不支援序列化,則不能儲存到這種模式(非InProc)的Session裡。
問:為什麼每次請求的SessionID都不相同?
答:該問題可能是沒有在Session裡面儲存任何資訊引起的,即程式中任何地方都沒有使用Session。當Session中儲存資訊之後SessionID将一直和浏覽器相關,此時的SessionID将不會在變化。