在ASP.NET的開發(fā)中,總遇到Session丟失.最常見的情況是當用戶登錄后將用戶信息保存在Session中例如Session["user"]=user;在其后的頁面中檢查Session["user"]是否為空,如果為空則要求用戶重新登錄,我們遇到的問題是在用戶登錄后的1小段時間后(也許只有5分鐘),Session["user"]就已經(jīng)丟失了,Session["user"]!=null的判斷就不成立了.

遇到這樣的問題我們首先想到的可能是session過期了,需要設置web.config中session的過期時間,最常見的簡單設置就是:

<sessionState mode="InProc" timeout="20" />這里的timeout是指的session的過期時間單位是分鐘,但是通常這樣的設置還不能解決你的問題,因為session的默認過期時間就是20分鐘.

現(xiàn)在我們來看看session在web.config中的配置,完整的配置如下:

< sessionState mode ="Off|InProc|StateServer|SQLServer" 
                cookieless ="true|false" 
                timeout ="number of minutes" 
                stateConnectionString ="tcpip=server:port" 
                sqlConnectionString ="sql connection string" 
                stateNetworkTimeout ="number of seconds" />

其實我也很少使用上面這樣完全的配置,但是了解這樣配置的用法是我們解決session過期的方法之一,下面我們來看看這段配置的說明,下面這段文字來源于網(wǎng)絡,為了方便大家的查看將其拷貝過來了.

mode屬性 設置將Session信息存儲到哪里

Off 設置為不使用Session功能

InProc 設置為將Session存儲在進程內(nèi)，就是ASP中的存儲方式，服務器將Session信息存儲在IIS進程中,這是默認值。

StateServer 設置為將Session存儲在獨立的狀態(tài)服務中。

SQLServer 設置將Session存儲在SQL Server中。

cookieless屬性 設置客戶端的Session信息存儲到哪里

ture 使用Cookieless模式

false 使用Cookie模式，這是默認值。

timeout屬性 設置經(jīng)過多少分鐘后服務器自動放棄Session信息。默認為20分鐘 ,也就是我們通常說的過期時間.

stateConnectionString屬性 設置將Session信息存儲在狀態(tài)服務中時使用的服務器名稱和端口號，例如："tcpip=127.0.0.1:42424”。當mode的值是StateServer是，這個屬性是必需的。

sqlConnectionString屬性 設置與SQL Server連接時的連接字符串。例如"data source=localhost;Integrated Security=SSPI;Initial Catalog=northwind"。當mod e的值是SQLServer時，這個屬性是必需的 。

stateNetworkTimeout屬性 設置當使用StateServer模式存儲Session狀態(tài)時，經(jīng)過多少秒空閑后，斷開Web服務器與存儲狀態(tài)信息的服務器的TCP/IP連接的。默認值是10秒鐘。

第二個解決此問題的方法就是,不使用Inproc模式保存session而改用StateServer模式保存.

使用上面的配置需要關注下面的幾個問題:

1.要在服務中開啟“ASP.NET State Service”服務(設為“自動”)

2.如果stateConnectionString的值不是127.0.0.1或者localhost等代表本地地址的值，需要修改注冊 表：HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/aspnet_state /Parameters 節(jié)點 → 將 AllowRemoteConnection 的鍵值設置成“1”(1 為允許遠程電腦的連接，0 代表禁止)→ 設置 Port (端口號)

3.session中存儲非序列化的對象，如果違反會拋出 無法序列化會話狀態(tài)。在 “StateServer”或“SQLServer”模式下，ASP.NET 將序列化會話狀態(tài)對象，因此不允許使用無法序列化的對象或 MarshalByRef 對象。如果自定義會話狀態(tài)存儲在“Custom”模式下執(zhí)行了類似的序列化，則適用同樣的限制。 這樣的異常。如果向session存儲自定義的對象，那么該對象的類上一定要加上[Serializable]注釋,在本例中需要將user的類型標注為可序列化。

下面我們來看看Inproc模式和StateServer模式的優(yōu)缺點:

InProc模式

優(yōu)點：獲取session狀態(tài)的速度快，session狀態(tài)直接存儲在iis的進程中。

缺點：易丟失，經(jīng)常需要重新登錄,實際上在幾個項目中我也遇到了這個問題.

StateServer模式

優(yōu)點：session狀態(tài)單獨存儲在一個進程中，不會因為iis或者應用的重啟而丟失狀態(tài)

缺點：獲取session狀態(tài)的速度比InProc慢一些，畢竟是兩個不同的進程。

也許你想找出session在什么地方弄丟的,那么你可以嘗試下面的操作:

你還記得ASP.NET中有個global.asax文件嗎?里面有兩個關于session的兩個事件

Session_Start ：在一個新用戶訪問應用程序 Web 站點時，該事件被觸發(fā)。

Session_End ：在一個用戶的會話超時、結束或他們離開應用程序 Web 站點時，該事件被觸發(fā)。

以上就是關于“session丟失的解決方法”的介紹，如果您想了解更多相關知識，不妨來關注一下動力節(jié)點的Java在線學習，里面的課程內(nèi)容詳細，從入門到精通都有，適合沒有基礎的小伙伴學習，希望對大家能夠有所幫助。