Asp.Net Session学习总结
ASP.NET 中的 Session 怎么正確使用
https://www.cnblogs.com/ideacore/p/6423281.html
Session對象用于存儲從一個用戶開始訪問某個特定的aspx的頁面起,到用戶離開為止,特定的用戶會話所需要的信息。用戶在應用程序的頁面切換時,Session對象的變量不會被清除。?
對于一個Web應用程序而言,所有用戶訪問到的Application對象的內容是完全一樣的;而不同用戶會話訪問到的Session對象的內容則各不相同。 Session可以保存變量,該變量只能供一個用戶使用,也就是說,每一個網頁瀏覽者都有自己的Session對象變量,即Session對象具有唯一性。?
最近這兩天被一個Web Farm環境下的Session處理問題虐得很痛苦,這是一個ASP.NETSession基礎知識的一個合集,有的地方感覺是有重復,比較啰嗦,我基本上按照原文將他翻譯出來了,小弟程序水平不高,英語水平更差(09年高考英語65分,滿分150),自我感覺Session基礎內容是講清楚了,我粗淺的理解下,沒有發現有什么錯誤了,文章較淺,請各位發現有什么不對的地方告訴我,我一定盡快處理,這篇文章很適合初學者看,作者說的很清楚,能把ASP.NET下Session的玩法看得較為清晰。另外我會在我另一篇博文中將我所遇到的問題以及解決辦法和大家共享。原文地址:http://www.codeproject.com/Articles/32545/Exploring-Session-in-ASP-Net
這篇文章將使你非常好地理解Session,在這篇文章中,我會包含Session的基礎知識,用不同的方式儲存Session對象,包含Web園(Web Farm)和Web農場(Web Garden)以及負載均衡等等情境。我也將詳細闡明Session在實際生產環境中的應用。希望您能喜歡這篇文章,歡迎您反饋您的看法和建議。
什么是Session
Web是無狀態的,他提供了一種新的方式:每次都通過用戶對服務器提交請求而渲染新的網頁。眾所周知,HTTP是一種無狀態協議,他不能通過頁面和客戶端保持連接。如果用戶需要增加一些信息和跳轉到了另外的頁面,原有的數據將會丟失,用戶將無法恢復這些信息。我們需要這玩意兒干嘛呢?我們需要保存信息!Session提供了一個在服務器端保存信息的方案。他能支持任何類型對象和用戶對象信息作為對象保存起來。Session為每一個客戶端都獨立地保存,這意味著Session數據存儲著每個客戶端的基礎信息。請看下圖:
每一個客戶端都有一份獨立的Session
用Session進行狀態管理是ASP.NET最好的特性之一,因為它是安全的,對于客戶端是透明的,并且他能存儲任何類型的對象。而在這些優點之外,有時Session會導致一些對性能要求較高的網站的性能問題。因為他消耗服務器的內存存儲用戶訪問網站所需的數據,現在讓我們來看一看Session對于您Web 應用的利弊。
Session的利弊
接下來我們討論普通情況下使用Session的利弊,我會描述每一種Session的使用情境。
優點:
他能在整個應用中幫助維護用戶狀態和數據。
他能讓我們簡單地實現存儲任何類型的對象。
獨立地保存客戶端數據。
對于用戶來說,Session是安全的、透明的。
缺點:
因為Session使用的是服務器的內存,所以在用戶量大的時候會成為性能瓶頸。
在序列化和反序列化的過程中他也會成為性能瓶頸,因為在StateServer(狀態服務)模式和sql server模式下我們需要對我們存儲的數據進行序列化和反序列化我們所存儲的數據。
除此之外,Session的各種模式都有其利弊。接下來我們將討論各種Session模式。
對Session進行讀/寫
讀/寫Session是非常簡單的,就像使用ViewState一樣,我們能使用System.Web.SessionState.HttPSessionState這個類來與Session進行交互,這個類在ASP.NET頁面內內建(提供)了Session。下面的代碼就是使用Session進行存儲的例子:
//Storing UserName in Session<br>Session["UserName"] = txtUser.Text;
接下來讓我們來看如何從Session讀取數據:
//Check weather session variable null or not<br>if (Session["UserName"] != null)<br>{<br> //Retrieving UserName from Session
? ? lblWelcome.Text = "Welcome : " + Session["UserName"];<br>}else<br>{<br> //Do Something else<br>}
我們也能存儲其他對象,下面的例子展示了如何存儲一個DataSet到Session里
//Storing dataset on Session<br>Session["DataSet"] = _objDataSet;
下面的代碼展示了如何從Session內讀取DataSet
//Check weather session variable null or not
if (Session["DataSet"] != null)
{
? ? //Retrieving UserName from Session
? ? DataSet _MyDs = (DataSet)Session["DataSet"];
}
else{
? ? //Do Something else
}
參考文獻:
MSDN (read the session variable section)
Session ID
ASP.NET使用了120bit的標識符用以標識每個Session。這是足夠安全的、不可逆的設計。當客戶端和服務端進行通信的時候,在他們之間需要傳輸這個Session ID,當客戶端發送request(請求)數據時,ASP.NET搜索Session ID,通過Session ID檢索數據。這個過程通過以下步驟進行:
客戶端點擊網站->客戶端信息被Session儲存
服務端為客戶端創建一個唯一的Session ID,并在服務端存儲這個ID
客戶端通過發送帶有SessionID的請求以獲取在服務端保存的信息
服務器端通過Session Provider從狀態服務(State Server)中獲取序列化后的數據并且進行類型強制轉換成對象
以下為流程圖片:
客戶端、Web服務器、Session Provider的通信
參考文獻:
SessionID in MSDN
Session模式和Session Provider
在ASP.NET中,有以下幾種Session模式可以使用
InProc
StateServer
SQLServer
Custom
每一種Session State都有一種Session Provider。以下的圖形將展示他們的關系:
Session state體系圖
我們能在這些基礎的Session State Provider中進行選擇。當ASP.NET接收到帶有Session ID的信息請求時Session State和他相應的Provider負責提供和存儲對應的信息。下面的表展示了Session 模式以及Provider的名稱:
Session State模式?? ?State Provider
InProc?? ?In-memory object(內置對象)
StateServer?? ?Aspnet_state.exe
SQLServer?? ?SQL Server Database
Custom?? ?Custom provider
除此之外,還有另一個模式:“OFF”,如果我們選擇這個選項,Session將不能為這個應用提供服務。但是我們的目標是使用Session,所以我們將討論上面四種的Session模式。
Session States
Session State模式基本上可以認為把所有的Session配置、維護都交給了Web應用。Session State他本身就是一個大東西,他基本上意味著你所有關于Session 的配置無論實在web.config或者頁面后端代碼。在web.config里元素被用作Session的配置。在元素中可以配置的有Mode(模式),Timeout(超時),StateConnectionString(State連接字符串),CustomProvider(自定義的Provider)等等。我們已經討論過了每個部分的連接字符串在我們討論Session mode之前,接下來我們簡述以下Session的一些事件:
Session事件
在ASP.NET中有兩個可以使用的Session事件:
Session_Start
Session_End
你能處理應用中的這兩個事件在global.asax這個文件里,當一個新的Session開啟時session_start事件被觸發,當Session被回收或是過期時Session_End被觸發:
void Session_Start(object sender, EventArgs e)
{
? ? // Code that runs when a new session is started
}
void Session_End(object sender, EventArgs e){
? ? // Code that runs when a session ends.
}
參考文獻:
Application and Session Events
Session 模式
我們已經討論過Session模式,接下來說說這些模式的不同:
Off
InProc
StateServer
SQLServer
Custom
如果我們在web.config內設定Session Mode=”off”,Session將在應用中不可用,他的設置是這樣的:
InProc Session 模式:
這是ASP.NET默認的Session模式,他在當前的應用程序域中存儲Session信息。這是性能最好的Session模式。但是他最大的缺點在于:當我們重啟服務的時候Session數據將會丟失。InProc模式有一些優缺點,接下來我們將詳細這些點。
InProc概述:
我們已經說過,InProc模式Session數據將會儲存在當前應用程序域中,所以他是最簡單、快速、好用的。
InProc模式Session數據保存在應用程序域內的一個集合對象,他在一個應用程序池中進行工作,如果我們重啟服務,我們將丟失Session數據。正常情況下客戶端發送請求,State Provider從內存對象中讀取數據并返回給客戶端,在web.config中我們必須提供Session模式和設置過期時間:
上面的設置中,設置了Session的過期時間為30分鐘,這也可以從后臺代碼中進行配置。
Session.TimeOut=30;
在ASP.NET中有兩個Session事件可以進行使用:Session_Start()和Session_End()而這種模式(后端代碼控制)只支持Session_End()事件。這個事件在Session超時時被調用,一般情況下,InProc Session模式是這樣的:
當Session過期時Session_End()事件被調用。InProc是一個非??斓奶幚頇C制,因為沒有序列化地讀/寫過程,并且數據保存在相同的域內。
什么時候我們使用InProc模式呢?
InProc是默認的Session模式,他對小型應用程序和用戶量比較小的程序非常合適,我們應盡量避免在Web園(Web Garden)和Web農場(Web Farm)情境下使用他(以后我會講到這個情境)
優缺點:
優點:
他把Session數據存儲在當前應用程序域內,所以訪問數據會非常的快速、簡單、高效。
在InProc模式中不需要對對象進行序列化存儲。
使用起來非常簡單,就像ViewState一樣。
缺點:
雖然InProc是最快的,最通用的,也是默認的機制,但是他有許多限制:
如果工作的應用進程被回收,Session數據將全部丟失。
雖然他是最快的,但是當Session數據太大和用戶過多時,他會由于內存的大量使用而影響整個程序的性能。
我們不能在Web園環境中使用這種模式。
這種模式不適合用于Web農場(Web Farm)環境中。
現在,我們來看看其他可用的方法來規避這些缺點,首先是StateServer模式:
StateServer Session模式
StateServer模式概述
這也叫做Out-Proc Session模式。StateServer使用了一個獨立的Windows服務來提供Session服務,他獨立于IIS,也能獨使用一臺服務器。StateServer的服務來自于aspnet_state.exe提供。這個服務也能和您的應用服務共同運行在同一臺服務器上,注意他是獨立于Web應用程序域的一個服務。這意味著你重啟你的Web服務后Session數據依然存在。這個方案的缺點在于有一個性能瓶頸:數據讀寫需要進行序列化和反序列化,因為不是同一個應用程序域,所以他也增加了數據讀寫的性能消耗,因為他們是兩個不同的進程。
配置StateServer Session模式
在StateServer模式里,Session數據存儲在獨立于IIS的一個服務里。這個進程作為一個Windows服務運行,你能在Windows服務管理器(MMC)或者命令行中進行啟動。
默認情況下,ASP.NET StateServer(中文名:ASP.NET狀態服務)默認情況下啟動方式是“手動”我們必須將他設置為自動。
如果從命令行啟動的化只需要輸入:”net start aspnet_state”;默認情況下,這個服務監聽TCP端口42424,但是我們可以在注冊表里改變這個設置,如圖:
現在,我們來看一看web.config對StateServer的設置,在StateServer的設置里我們需要指定StateServer連接字符串stateConnectionString:指向運行StateServer的系統。默認設置下,StateConnectionString使用IP127.0.0.1(localhost)端口使用42424。
當我們使用StateServer,我們還能設置超時stateNetworkTimeOut特性指定等待服務響應的秒數,即發出請求到取消響應的事件時間間隔。默認情況下是10秒。
當使用StateServer進行存儲時對象將被序列化進行儲存,而讀取對象時,將對數據進行反序列化,我們來看下面的例子:
StateServer是如何工作的
我們使用StateServer來避免當重啟Web服務時無謂的Session數據丟失。StateServer是在aspnet_state.exe進程作為一個服務來進行維護的,這個進程維護著所有的Session數據,但是在存儲到StateServer之前我們需要對數據進行序列化。
如上圖所示,客戶端發送請求到Web服務器,Web服務器將Session數據存儲在StateServer里,StateServer也許在當前的系統里,也可能在另一個系統里,但他一定是獨立于IIS的,為了實現他,我們必須在web.config里進行配置stateConnectionString。例如我們設置指向127.0.0.1:42424,這將把數據存儲在本地的系統內,為了實現改變StateServer指向的目的,我們改變了IP,并且確定aspnet_state.exe正常運行于這個系統上,接下來當你需要讀寫Session時(也就是通過修改IP來導致一個錯誤的指向),你就會引發下圖這樣的異常:
當我們存儲一個對象到Session,對象將被序列化。系統利用State Provider將數據存儲進StateServer。當讀取數據時,State Provider將返回數據,完整的流程圖如下圖:
StateServer Session模式例子:
這是一個簡單的使用StateServer Session模式的例子,我直接在IIS里創建這個例子,能輕松地明白他的用法:
步驟1:打開Visual Studio>文件>新建>網站。選擇HTTP作為web應用的位置。
現在你打開IIS,你將會看到創建了一個虛擬目錄,名字是你的應用名,在我的例子中是StateServer。
步驟2:創建一個簡單的UI:他將獲取一個學生的角色編號和名字,我們將保存名字和編號到StateServer Session里。我也將創建一個類:StudentInfo,這個類的定義如下:
[Serializable]
public class StudentInfo
{
? ? //Default Constructor
? ? public StudentInfo(){}
? ? // Create object of student Class
? ? //Int RollNumber
? ? ///String Name
? ? public StudentInfo(int intRoll, string strName)
? ? {
? ? ? ? this.Roll = intRoll;
? ? ? ? this.Name = strName;
? ? }
? ? private int intRoll;
? ? private string strName;
? ? public int Roll{
? ? ? ? get{return intRoll;}
? ? ? ? set{intRoll = value;}
? ? }
? ? public string Name{
? ? ? ? get{return strName;}
? ? ? ? set{strName = value;}
? ? }
} ? ? ? ? ??
現在來看后端代碼,我增加了兩個Button:一個是保存Session,另一個是獲取Session:
protected void btnSubmit_Click(object sender, EventArgs e)
{
? ? StudentInfo _objStudentInfo =new StudentInfo(Int32.Parse( txtRoll.Text) ,txtUserName.Text);
? ? Session["objStudentInfo"] = _objStudentInfo;ResetField();
}
protected void btnRestore_Click(object sender, EventArgs e)
{
? ? StudentInfo _objStudentInfo = (StudentInfo) Session["objStudentInfo"];
? ? txtRoll.Text = _objStudentInfo.Roll.ToString();
? ? txtUserName.Text = _objStudentInfo.Name;
}
步驟3:配置你的web.config的StateServer,在之前介紹過,請確保web.config在配置所指向的服務器上的State Server是處于開啟并運行的狀態。
步驟4:運行應用。
輸入數據,點擊Submit。
接下來的測試,我將完整的解釋如何使用StateServer
首先:移除StudentInfo類[Serializable]特性,然后運行應用。當你點解Submit按鈕,你將看到如下的錯誤:
清晰地指出了在存儲之前你必須序列化你的對象。
第二:運行程序,在點擊了Submit按鈕保存數據后,重啟IIS
如果在InProc中,我保證你的Session數據將會丟失,但是在StateServer中,點擊Restore Session按鈕,你將獲取你的原始數據,因為StateServer數據不依賴于IIS,它獨立地保存數據。
第三:在Windows 服務管理程序(MMC)中停止StateServer服務,你再點擊Submit按鈕,你將看到如下錯誤:
因為你的StateServer進程沒有運行,所以當你在使用StateServer的時候,請牢記這三點。
優點和缺點
基于上述討論:
優點:
StateServer獨立于IIS運行,所以無論IIS出什么問題都影響不到StateServer的數據。
他能在Web Farm和Web Garden環境中使用。
缺點:
要進行序列化和反序列化,拖慢速度。
StateServer需要保證正常運行。
我在這里停止StateServer的講述,你將在負載均衡中看到他更多更有趣的點,Web Farm,Web Garden情境下。
參考文獻:
State Server Session Mode
ASP.NET Session State
SQL Server Session模式
SQL Server模式簡介
ASP.NET這個Session模式提供給我們了更強的安全性和可靠性,在這個模式下,Session數據被序列化并存儲到一個SQL Server的數據庫中,這個模式缺點在于Session需要序列化和反序列化的讀寫方式成為了主要的性能瓶頸,他是Web Farm的最佳選擇。
設置SQL Server,我們需要這些SQL腳本:
安裝:InstallSqlState.sql
卸載:UninstallSQLState.sql
最簡單的配置方式是利用aspnet_regsql命令。
之前已經解釋過了如何配置,這是最有用的狀態管理方法在web Farm模式里。
我們為何使用SQL Server模式?
SQL Server Session模式提供了更安全、更可靠的Session管理。
他保證了數據在一個集中式的環境中(數據庫)。
當我們需要更安全地實現Session時就應該使用SQL Server模式。
假如服務器經常需要重啟,這是一個完美的解決方案。
這是一個完美解決web Farm和web園的方案(這個我將在后面詳細解釋)。
當我們需要在兩個應用間共享Session時我們需要使用SQL Server模式。
配置SQL Server Session模式
在SQL Server模式中,我們的數據保存在SQL Server中,所以我們首先要在web.config里提供數據庫連接字符串,sqlConnectionString是被用來做這事的。
在連接字符串配置完成后,我們將要配置SQL Server,我將在這里演示如何用aspnet_regsql命令進行數據庫配置。
第一步:進入命令行,進入到Framework version目錄E.g. :c:\windows\microsoft.net\framework\。
第二步,帶參運行aspnet_regsql命令。
下面是參數的使用:
Parameters?? ?Description
-ssadd?? ?增加 SQLServer 模式 session state.
-sstype p?? ?P 持久化.將這些數據持久化存儲于數據庫中
-S?? ?服務器名
-U?? ?用戶名
-P?? ?密碼.
?
運行結束后,你見看到如下的信息:
配置結束。
第三步:
打開SQL Server,查看數據庫ASPState庫,將有兩張表:
ASPStateTempApplications
ASPStateTempSessions
更改設置中的連接字符串,建立一個像StateServer例子中那樣的應用
點擊Submit時保存Roll Number和用戶名,打開數據庫,進入ASPStateTempSessions表,這是你保存的Session數據:
現在我們再來討論以下StateServer模式中所討論的幾個問題:
1、從StydentInfo類中移除Serialize特性(keyword)
2、重啟IIS再讀取Session數據
3、停止SQL Server服務
我想這些問題我已經在StateServer解釋得很清楚了。
(注:第一種將導致無法序列化對象,會拋出異常,第二種無影響,第三種,在關閉數據庫服務時會有影響,而重啟數據庫服務將找回Session內的數據,因為他是持久化儲存的。)
優缺點
優點:
Session數據不受IIS重啟的影響
最可靠和最安全的Session管理模式
他在本地中心化保存Session數據,能使其他應用方便地進行訪問
在Web Farm 和Web Garden情境下非常實用
缺點:
和默認模式比較起來,會顯得很慢
對象的序列化和反序列化會成為性能瓶頸
因為需要在不同的服務器上訪問SQL Server,我們必須保證SQL Server的穩定運行。
參考資料:
Read more about SQLServer mode
自定義Session模式
通常情況下,我們使用InProc模式、StateServer模式、SQL Server模式就夠了,可是我們還是需要了解一些用戶自定義Session模式的相關知識。這是一種相當有趣的Session模式,因為用戶的Session全部交由了我們進行控制,甚至Session ID,你都能通過自己寫算法來生成Session ID。
你能夠容易地從基類SessionStateStoreProviderBase開發出自定義的Provider,你也能通過實現ISessionIDManager接口來產生SessionID。
下圖是自定義方法的處理過程:
在Initialize方法中,我們能設置一個自定義Provider。他將提供給Provider初始化連接。SetItemExpireCallback被用作提供SessionTimeOut(Session過期),當Session過期時我們能注冊一個方法進行調用。InitializeRequest在請求發起的時候被調用,CreateNewStoreData在創建一個SessionStateStoreData(Session數據存儲類)實例時候被調用。
我們何時使用自定義Session模式?
1、 當我們想將Session數據存儲在SQL Server之外的數據庫內時。
2、 當我們必須使用一個已存在的(特定的)表來存儲Session數據的時候。
3、 當我們需要使用自定義的SessionID的時候
如何配置自定義Session模式?
我們需要在web.config里進行這樣的配置:
如果你想了解更多的關于自定義模式的信息,請查閱參考資料。
優缺點:
優點:
1、 我們能使用一個已存在的表(指定的表)來存儲Session數據。當我們使用一個之前使用的數據庫時,這樣做是很有用的。
2、 他獨立于IIS運行,所以重啟服務器對他也沒有影響。
3、 我們能建立自己的Session ID邏輯來分配Session ID。
缺點:
1、 處理數據很慢。
2、 創建一個自定義的Session狀態Provider是一個基礎性(low-level)任務,他需要小心處理各種情況以及保證數據安全。
我推薦您使用第三方提供的Provider而不是自己寫一套Provider。
參考資料:
Custom Mode
生產部署的概述:
在實際的生產工作環境中部署我們的應用對于一個Web開發者來說是一個非常重大的挑戰。因為在大的生產環境中,有大量的用戶數據需要處理,數據量大到一臺服務器難以負載這么巨大的數據處理量。這個概念來自于Web Farm,Web Garden,負載均衡的使用。
在幾個月前,我部署了一個實際環境:這個環境要處理百萬級的用戶訪問以及超過10個域控制器,通過負載均衡搭載了超過10臺服務器和服務數據庫。例如交易服務器、LCS服務器。最大的挑戰來自于跨多個服務器的Session管理。下圖對這個生產環境展示了一個簡單的圖形:
我將試著解釋并讓您記住各個不同應用場景。
應用程序池
這是當您在創建一個實際生產環境時最重要的一個東西。應用程序池是用在IIS里用來分隔不同的工作進程的應用程序的,應用程序池能分隔我們的應用程序,使其獲得更好的安全性,可靠性和有效性。應用程序池的應用在服務器中當一個進程出現問題,或者被回收時其他進程不受影響。
應用程序池的角色:
應用程序池的配置角色是一個重要的安全措施,在IIS6和IIS7里。因為當應用程序訪問資源時他指定了應用程序的身份。在IIS7里,有三種預定義的身份指定方式,這和IIS6是一樣的。
應用程序池角色?? ?描述
LocalSystem?? ?內建于服務器上管理權限的賬戶. 他能訪問本地和遠程資源. 任何服務器的文件或者資源, 我們必須把應用程序的身份設置為LocalSystem.
LocalServices?? ?內置的本地身份驗證. 他不能進行任何網絡訪問。
NetworkServices?? ?這是應用程序池的默認身份,NetworkServices是一個經過驗證的本地用戶賬戶權限。
建立和指定應用程序池
打開IIS管理頁面,右鍵單擊應用程序池目錄->新建
給應用程序池一個ID,然后點擊OK。
現在,右鍵單擊一個虛擬目錄(我正在使用的StateServer站點)分配StateServerAppPool給StateServer虛擬目錄。
現在這個StateServer站點運行在了一個指定的獨立的應用程序池StateServerAppPool里。其他任何應用都不會影響到這個程序。這是獨立應用程序池的主要優點。
Web Garden
默認情況下,每一個應用程序池都運行在一個獨立的工作進程里(W3Wp.exe)。我們能分配多個進程給單個應用程序池,一個應用程序池跑多個進程,這樣的情況叫做Web Garden(Web園),多個工作進程單個應用程序在很多情況下都能夠有更優秀的輸出性能和更少的相應時間,每一個工作進程都會有他們自己的線程和內存空間。
如上圖所示,在IIS里,將會有多個應用程序池,并且每個應用程序池至少有一個工作進程,而一個Web Garden將有多個工作進程。
在你的應用程序里,使用Web園將必然出現一個限制條件:如果我們使用InProc模式,我們的應用程序將無法正確的工作,因為Session將工作在不同的進程里。為了避免這樣的問題,我們將使用進程外(OurProc)的Session模式,我們可以使用State Server或者SQL Server Session模式。
主要優點:
在Web園內的工作進程對每個進程都共享請求,如果一個進程掛了,其他的進程還能正常工作,繼續處理請求。
如何建立一個Web Garden?
右鍵單擊程序池->Performance(性能?)選項卡->選擇Web Garden(Web園)部分
默認情況下他的值為1,現在把他改為一個比1大的數字。
如何在Web園內指定Session?
我已經解釋過InProc模式是在單個工作進程中進行處理,在進程內存儲對象,現在,如果我們要處理多個進程,Session處理將會變得很困難,因為每個工作進程獨享自己的內存。那么假如第一個請求數據到了WP1并且保存了Session數據,第二個請求到了WP2我將無法正確獲得Session的數據,取值的話將會拋出異常。所以,請避免在Web Garden模式下使用InProc模式。
我們使用StateServer或者SQLServer模式對這種情況進行處理,之前解釋過,這兩種模式不依賴于工作進程,在之前的例子里也說過當IIS重啟你依然能訪問到Session數據。
Session模式?? ?是否推薦
InProc?? ?No
StateServer?? ?Yes
SQLServer?? ?Yes?
Web Farm和負載均衡
這是在生產環境中最常見的情形,當你需要在多臺服務器上部署你的應用時,使用這種模式的主要原因是我們要將負載均衡到多臺服務器上,一個負載均衡器被用于分發負載到多臺服務器上。
我們來看上圖,客戶端通過URL發送請求時先到負載均衡器,然后通過負載均衡器將請求分發給服務器,負載均衡器將在不同的服務器之間進行請求的分發。
現在我們如何處理我們的Session呢?
在WEB Farm和負載均衡情況下處理Session
在Web Farm中處理Session是一個有挑戰性的工作。
InProc:InProc Session模式,Session數據以對象形式被存儲在工作進程中,每個服務器將有他自己的工作進程,并將保持Session數據在內存中。
假如一臺服務器down了,那么請求將會訪問其他服務器,而其他服務器里是不存在相應Session數據的。所以在Web Farm情形下不推薦使用InProc模式。
State Server:之前已經解釋過如何使用和配置StateServer模式了,在WebFarm的環境下你將了解他是多么的重要,因為所有Session數據將在一個位置進行存儲。
記住,在web Farm環境里,你必須保證你有相同的節在你所有的web服務器上,其他配置和之前描述的一致,所有的web.config文件都要有相同的配置屬性(stateConnectionString)在Session State里。
SQL Server:這是另一個選擇,這也是在Web Farm環境里的最佳選擇,我們首先需要配置數據庫,接下來的步驟之前已經說過了。
如上圖所示,所有的web服務器Session數據都將被存儲于一個SQL Server數據庫。請記住一點,在StateServer模式和SQL Server模式下你都將把對象進行序列化存儲。當一臺Web服務器掛掉的時候,負載均衡器將把請求分發到其他服務器他將能從數據庫里取出Session數據,因為所有Session數據都是存放于數據庫里的。
總之,我們能用StateServer和SQL Server模式來進行Web Farm的部署,我們需要盡量避免使用InProc模式。
Session和Cookie
客戶端使用Cookie來配合使用Session,因為客戶端需要給每個請求提供合適的Session ID,我們可以使用下列的方法:
使用Cookie
ASP.NET使用了一個特定的Cookie名叫作:ASP.NET_SessionId這是當Session集合被創建的時候自動提供的,這是默認設置,Session ID通過Cookie進行傳送。
Cookie Munging
當用戶向服務器發送一個請求時,服務器解碼Session ID并將他加入到每個頁面的鏈接里,當用戶點擊鏈接,ASP.NET編碼Session ID并傳送到用戶所請求的頁面,現在,請求的頁面可以獲取Session變量了。這一切都是自動完成的,當ASP.NET發現用戶瀏覽器不支持Cookie時。
如何實現Cookie Munging
為了這個,我們必須保證我們的Session State為Cookie-less。
移除Session
下面的方法被用來移除Session
方法?? ?描述
Session.Remove(strSessionName)?? ?從Session State中移除一個項目
Session.RemoveAll()?? ?從Session集合中移除所有項目
Session.Clear()?? ?從Session集合中移除所有項目. Note: Clear和RemoveAll.RemoveAll()沒有區別Clear()是內部的.
Session.Abandon()?? ?取消當前的Session。
啟用和禁用Session
從性能優化來說,我們可以啟用或禁用Session,因為每個頁面都進行讀寫Session會出現一些性能開銷,所以,更合適地啟用或者禁用Session,而不是使用他的默認配置:always。我們啟用和禁用Session可以采取兩種方式:
頁面級
應用級
頁面級
我們能禁用Session在頁面指令的EnableSessionState屬性中
同樣的,我們可以讓他成為只讀的,這將只允許訪問Session而禁止寫入信息到Session
應用級
通過設置web.config的屬性EnableSessionState可以讓Session在整個應用程序內被禁用,
一般我們都是采用頁面級的限制,這樣能靈活控制Session的使用。
參考文獻:
How to Disable ASP.NET Session State
總結
希望你現在能更熟悉Session了,如何使用Session,以及如何在Web Farm中使用,總結如下:
1、 InProc Session Provider是最快的,因為所有數據都存在應用程序的內存里,Session數據在IIS重啟,或者站點被回收的情況下丟失,你可以在用戶量較小的網站上使用這種模式,但別在Web Farm下使用。
2、 State Server模式:Session數據被存儲于aspnet_state.exe應用中,他在Web服務之外保存Session數據,所以Web服務出現問題不會對他的Session數據造成影響,在將Session數據存儲到StateServer之前需要序列化對象,在Web Farm中我們能安全地使用這個模式。
3、 SQL Server模式:他將Session數據保存到SQL Server中,我們需要提供連接串,我們存儲時也需要對對象進行序列化,這種模式在實際Web Farm的生產環境中是非常有用的。
4、 我們也能使用自定義模式,當我們需要使用一個已經存在的表來存儲Session數據時,在自定義模式中,我們也能創建自定義的Session ID,但是不推薦你自己來實現Provider,推薦使用第三方的Provider。
========
ASP.NET Session 簡單超實用使用總結
https://www.cnblogs.com/yinrq/p/5032493.html
一、概述
Session用于存儲特定的用戶會話所需的信息 。 Session對象的引入是為了彌補HTTP協議的不足,HTTP協議是一種無狀態的協議。
Session中文是“會話”的意思,在ASP.NET中代表了服務器與客戶端之間的“會話”。Session的作用時間從用戶到達某個特定的Web頁開始,到該用戶離開Web站點,或在程序中利用代碼終止某個Session結束。引用Session 則可以讓一個用戶訪問多個頁面之間的切換也會保留該用戶的信息。
系統為每個訪問者都設立一個獨立的Session對象,用以存儲Session變量,并且各個訪問者的Session對象互不干擾。
Session與Cookie是緊密相關的。 Session的使用要求用戶瀏覽器必須支持Cookie,如果瀏覽器不支持使用Cookie,或者設置為禁用Cookie,那么將不能使用Session。
Session信息對客戶來說,不同的用戶用不同的Session信息來記錄。當用戶啟用Session時,ASP自動產生一個SessionID.在新會話開始時,服務器將SessionID當做cookie存儲在用戶的瀏覽器中。
二、Session數據存放的位置和形式
web.config 配置節點語法:
<system.web>
<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"
/>
</system.web>
mode:設置將Session信息存儲到哪里
? ? ? ? Off:不使用Session功能;?
? ? ? ? InProc :將Session存儲在IIS進程內,這是默認值,也最常用(優點是簡單,性能最高。但是當重啟IIS服務器時Session丟失。);?
? ? ? ? StateServer :將Session存儲在ASP.NET狀態服務進程中(重新啟動Web應用程序時保留會話狀態,并使會話狀態可以用于網絡中的多個Web服務器。);?
? ? ? ? SQLServer :將Session存儲在SQL Server中(存儲在內存和磁盤中,服務器掛掉重啟后都還在)。?
cookieless:設置客戶端的Session信息存儲到哪里
? ? ? ? ture 使用Cookieless模式;這時客戶端的Session信息就不再使用Cookie存儲了,而是將其通過URL存儲。
? ? ? ? false 使用Cookie模式,這是默認值。
timeout 設置經過多少分鐘后服務器自動放棄Session信息。默認為20分鐘。?
stateConnectionString 設置將Session信息存儲在狀態服務中時使用的服務器名稱和端口號,例如:"tcpip=127.0.0.1:42424”。當mode的值是StateServer是,這個屬性是必需的。(默認端口42424)。?
sqlConnectionString 設置與SQL Server連接時的連接字符串。例如"data source=localhost;Integrated Security=SSPI;Initial Catalog=joye"。當mode的值是SQLServer時,這個屬性是必需的。
stateNetworkTimeout 設置當使用StateServer模式存儲Session狀態時,經過多少秒空閑后,斷開Web服務器與存儲狀態信息的服務器的TCP/IP連接的。默認值是10秒鐘。
三、Session的curd操作
代碼:
? ? ? ? ? ? ?//寫入
? ? ? ? ? ? Session["UserName"] = "joye888";
? ? ? ? ? ? //讀取
? ? ? ? ? ? var userName = Session["UserName"].ToString();
? ? ? ? ? ? Response.Write(userName);
? ? ? ? ? ? //遍歷
? ? ? ? ? ? IEnumerator sessionEnum = Session.Keys.GetEnumerator();
? ? ? ? ? ? while (sessionEnum.MoveNext())
? ? ? ? ? ? {
? ? ? ? ? ? ? ? Response.Write(Session[sessionEnum.Current.ToString()].ToString() + " ");
? ? ? ? ? ? }?
? ? ? ? ? ? //銷毀
? ? ? ? ? ? Session.Abandon(); //結束會話
? ? ? ? ? ? Session.Clear();//不結束會話
四、Session運行原理圖解
五、Session實際案例-在線購物車和Session配合驗證碼使用
代碼省略。
六、Session和Cookie的區別
1、cookie存客戶端,session存服務端。
2、cookie不是很安全,別人可以分析存放在本地的COOKIE并進行COOKIE欺騙。
3、session會在一定時間內保存在服務器上。當訪問增多,會比較占用你服務器的性能
考慮到減輕服務器性能方面,應當使用COOKIE。
4、單個cookie保存的數據不能超過4K,很多瀏覽器都限制一個站點最多保存20個cookie。
========
ASP.NET 狀態服務 及 session丟失問題解決方案總結
https://blog.csdn.net/qq_28960147/article/details/80964532
ASP.NET 狀態服務 及 session丟失問題解決方案總結
最近在開發一ASP.NET2.0系統時,在程序中做刪除或創建文件操作時,出現session丟失問題。在網上搜了不少資料,最后終于解決了,采用了如下方法:
1、asp.net Session的實現:
asp.net的Session是基于HttpModule技術做的,HttpModule可以在請求被處理之前,對請求進行狀態控制,由于Session本身就是用來做狀態維護的,因此用HttpModule做Session是再合適不過了。
ASP.NET中Session的狀態保持方式
ASP.NET提供了Session對象,從而允許程序員識別、存儲和處理同一個瀏覽器對象對服務器上某個特定網絡應用程序的若干次請求的上下文信息。Session對應瀏覽器與服務器的同一次對話,在瀏覽器第一請求網絡應用程序的某個頁面時,服務器會觸發Session_onStart事件;在對話超時或者被關閉的時候會觸發Session_onEnd 事件。程序員可以在代碼中響應這兩個事件來處理與同一次對話相關的任務,如開辟和釋放該次對話要使用的資源等。
? ?在ASP.NET的程序中要使用Session對象時,必須確保頁面的@page指令中EnableSessionState屬性是True或者Readonly,并且在web.config文件中正確的設置了SessionState屬性。
? ASP.NET中Session的狀態保持是由web.config文件中的<system.web>標記下的<sessionstate>標記的mode屬性來決定的。該屬性有四種可能的值:Off、Inproc、StateServer和SQlServer.
?設為Off會禁用Session.
? Inproc是缺省的設置,這種模式和以前的ASP的會話狀態的方法是類似的,會話的狀態會被保存在ASP.NET進程中,它的優點是顯而易見的:性能。進程內的數據訪問自然會比夸進程的訪問快。然而,這種方法Session的狀態依賴于ASP.NET進程,當IIS進程崩潰或者正常重起啟時,保存在進程中的狀態將丟失。
?為了克服Inproc模式的缺點,ASP.NET提供了兩種進程外保持會話狀態的方法。
? ASP.NET首先提供了提供了一個Windows服務:ASPState,這個服務啟動后,ASP.NET應用程序可以將mode屬性設置為“SateServer”,來使用這個Windows服務提供的狀態管理方法。
?除了在web.config文件中設置mode屬性為StateServer外,還必須設置運行StateServer服務器的IP地址和端口號.如果在IIS所在的機器運行StateServer則IP地址就是127.0.0.1,端口號通常是42424.配置如下:
?mode=”StateServer”
?stateConnectionString="tcpip=127.0.0.1:42424"
? ? 使用這種模式,會話狀態的存儲將不依賴IIS進程的失敗或者重啟,會話的狀態將存儲在StateServer進程的內存空間中。
? ?另一種會話狀態模式是SQLServer模式。這種模式是將會話的狀態保存在SQL Server數據庫中的。使用這種模式前,必須至少有一臺SQL Server服務器,并在服務器中建立需要的表和存儲過程。.NET SDK提供了兩個腳本來簡化這個工作:InstallSqlState.sql和UnInstallSqlState.sql。這兩國文件存放在下面路徑中:
? <%SYSTEMDRIVER%>/Winnt/Microsoft.NET/Framework/<%version%>/
要配置SQL Server 服務器,可以在命令行中運行SQL Server提供的命令行工具osql.exe
? osql -s [server name] -u [user] -p [password] <InstallSqlState.sql
例如:
? osql -s (local) -u as -p “”-i ?InstallSqlState.sql
做好必要的數據庫準備工作后,將web.config文件中的sessionstate元素的mode屬性改為”sqlserver”,并指定SQL連接字符串。具體如下:
? mode="SQLServer"
? ? sqlConnectionString="data source=127.0.0.1;userid=sa;password=;Trusted_Connection=yes"
使用SQLServer模式處了可以使Session的狀態不依賴于IIS服務器之外,還可以利用SQL Server的集群,使狀態存儲不依賴于單個的SQL Server,這樣就可以為應用程序提供極大的可靠性。
?
2、丟失原因:
轉(1):Asp.net 默認配置下,Session莫名丟失的原因及解決辦法
? ? ? 正常操作情況下Session會無故丟失。因為程序是在不停的被操作,排除Session超時的可能。另外,Session超時時間被設定成60分鐘,不會這么快就超時的。
? ? ? 這次到CSDN上搜了一下帖子,發現好多人在討論這個問題,然后我又google了一下,發現微軟網站上也有類似的內容。
現在我就把原因和解決辦法寫出來。
原因:
由于Asp.net程序是默認配置,所以Web.Config文件中關于Session的設定如下:
<sessionState
mode='InProc'
stateConnectionString='tcpip=127.0.0.1:42424'
sqlConnectionString='data source=127.0.0.1;Trusted_Connection=yes'
cookieless='true'
timeout='60'/>
我們會發現sessionState標簽中有個屬性mode,它可以有3種取值:InProc、StateServer?SQLServer(大小寫敏感)。默認情況下是InProc,也就是將Session保存在進程內(IIS5是aspnet_wp.exe,而IIS6是W3wp.exe),這個進程不穩定,在某些事件發生時,進程會重起,所以造成了存儲在該進程內的Session丟失。
[asp的Session是具有進程依賴性的。ASP Session狀態存于IIS的進程中,也就是inetinfo.exe這個程序。所以當inetinfo.exe進程崩潰時,這些信息也就丟失。]
哪些情況下該進程會重起呢?微軟的一篇文章告訴了我們:
1、配置文件中processModel標簽的memoryLimit屬性
2、Global.asax或者Web.config文件被更改
3、Bin文件夾中的Web程序(DLL)被修改
4、殺毒軟件掃描了一些.config文件。
更多的信息請參考PRB: Session variables are lost intermittently in ASP.NET applications
解決辦法:
? ? ? 前面說到的sessionState標簽中mode屬性可以有三個取值,除了InProc之外,還可以為StateServer、SQLServer。這兩種存Session的方法都是進程外的,所以當aspnet_wp.exe重起的時候,不會影響到Session。
? ? ? 現在請將mode設定為StateServer。StateServer是本機的一個服務,可以在系統服務里看到服務名為ASP.NET State Service的服務,默認情況是不啟動的。當我們設定mode為StateServer之后,請手工將該服務啟動。這樣,我們就能利用本機的StateService來存儲Session了,除非電腦重啟或者StateService崩掉,否則Session是不會丟的(因Session超時被丟棄是正常的)。
? ? ? 除此之外,我們還可以將Session通過其他電腦的StateService來保存[如使用狀態服務器]。具體的修改是這樣的。同樣還在sessionState標簽中,有個stateConnectionString='tcpip=127.0.0.1:42424'屬性,其中有個ip地址,默認為本機(127.0.0.1),你可以將其改成你所知的運行了StateService服務的電腦IP,這樣就可以實現位于不同電腦上的Asp.net程序互通Session了。
? ? ? 如果你有更高的要求,需要在服務期重啟時Session也不丟失,可以考慮將mode設定成SQLServer,同樣需要修改sqlConnectionString屬性。關于使用SQLServer保存Session的操作,請訪問這里。
? ? ? 在使用StateServer或者SQLServer存儲Session時,所有需要保存到Session的對象除了基本數據類型(默認的數據類型,如int、string等)外,都必須序列化。只需將[Serializable]標簽放到要序列化的類前就可以了。
如:
[Serializable]
public class MyClass
{
? ? ......
}
具體的序列化相關的知識請參這里。
至此,問題解決。
參考文章:
ASP.NET Session State FAQ
ASP.NET Session State
[ASP.NET] Session 詳解
PRB: Session Data Is Lost When You Use ASP.NET InProc Session State Mode
PRB: Session Data Is Lost When You Use ASP.NET InProc Session State Mode
ASP.NET HTTP 運行時
.NET 中的對象序列化
備注
(1)使用 StateServer 模式
確保運行 ASP.NET 狀態服務的服務器是要存儲會話狀態信息的遠程服務器。該服務與 ASP.NET 一起安裝,其默認位置為
<驅動器>:/systemroot/Microsoft.NET/Framework/version/aspnet_state.exe。?
在應用程序的 Web.config 文件中,
設置 mode=StateServer 并設置 stateConnectionString 屬性。
例如,stateConnectionString="tcpip=sarath:42424"。?
(2)使用 SQLServer 模式
在運行 SQL Server 的計算機(它將存儲會話狀態)上運行 InstallSqlState.sql
(默認的安裝位置為 <驅動器>:/systemroot/Microsoft.NET/Framework/version)。
這將創建一個名為 ASPState 的數據庫,該數據庫具有新的存儲過程并且在 TempDB 數據庫中具有 ASPStateTempApplications 表和 ASPStateTempSessions 表。
在應用程序的 Web.config 文件中,設置 mode=SQLServer 并設置 sqlConnectionString 屬性。例如,sqlConnectionString="data source=localhost;Integrated Security=SSPI;Initial Catalog=northwind"。?
(3)示例?
以下示例指定若干會話狀態配置設置。?
<configuration>?
<system.web>?
<sessionState mode="InProc"?
cookieless="true"?
timeout="20"/>?
</sessionState>?
</system.web>?
</configuration>?
要求?
包含于:<system.web>?
Web 平臺:IIS 5.0、IIS 5.1、IIS 6.0?
配置文件:Machine.config、Web.config?
配置節處理程序:System.Web.SessionState.SessionStateSectionHandler?
請參見
ASP.NET 配置 | ASP.NET 設置架構 | SessionStateModule
作者: ?來源: ?(責任編輯:webjx)--- -------------收集之二---------------------------------
[出現原因:]在Windows2003的服務器中的IIS6加入了應用程序池來回收一些無用的進程的功能,當由于網站程序的錯誤或訪問量太多的導致的應用程序池會自動回收該進程,防止網站進入“死機”狀態,而這時候的應用程序池的回收就會導致session變量被清除,就出現了session變量不見的現象。
為了解決這種在Windows2003下才出現的問題,我們在服務端起動ASP.NET State Service服務,并且在系統的machine.config做了一些改動。現在默認的情況下會話狀態mode是StateServer。如果您的網站根目錄下也配有一個web.config配置文件,請把mode="InProc"改成mode="StateServer",如下代碼,就可以防止session變量的丟失:
<sessionState?
mode="StateServer"?
stateConnectionString="tcpip=127.0.0.1:42424"?
sqlConnectionString="data source=127.0.0.1;Integrated Security=SSPI"?
cookieless="false"?
timeout="30"?
/>?
+ 注:只適用于支持asp.net的用戶。
?
轉(2):原因及一些解決之道
將Session保存在State Server里:
1.啟動服務“ASP.NET State Service”,
2.然后,修改web.config:
<sessionState
mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="140000"
/>
注意://mode="StateServer"這種模式下即使修改頁面也不會丟失session!
當然:mode="InProc"如果你的模式為這種,修改頁面的時候會丟失session!!!!!!
在WebConfig里將Session的Mode設成SQLServer或者StateServer都不會丟Session的,
前者需要寫入數據庫,后者需要系統開StateServer服務。
?
原因1:
bin目錄中的文件被改寫,asp.net有一種機制,為了保證dll重新編譯之后,系統正常運行,它會重新啟動一次網站進程,這時就會導致Session丟失,所以如果有access數據庫位于bin目錄,或者有其他文件被系統改寫,就會導致Session丟失。[目錄的刪除操作一定丟失session。asp.net的內部機制對待目錄有點像個守財奴,它死守著目錄,你創建它不會管(往里加),一但創建他就會監視該目錄,若你要刪除或重命名它的(動它的目錄),它就發生重起了。。]
原因2:
文件夾選項中,如果沒有打開“在單獨的進程中打開文件夾窗口”,一旦新建一個窗口,系統可能認為是新的Session會話,而無法訪問原來的Session,所以需要打開該選項,否則會導致Session丟失
原因3:
似乎大部分的Session丟失是客戶端引起的,所以要從客戶端下手,看看cookie有沒有打開
原因4:
Session的時間設置是不是有問題,會不會因為超時造成丟失。
[默認時間是20分鐘,可以在Web.Config中設置Session的timeOut,如改為60分鐘等]
原因5:
IE中的cookie數量限制(每個域20個cookie)可能導致session丟失
原因6:
使用web garden模式,且使用了InProc mode作為保存session的方式
解決丟失的經驗
1. 判斷是不是原因1造成的,可以在每次刷新頁面的時候,跟蹤bin中某個文件的修改時間。
2. 做Session讀寫日志,每次讀寫Session都要記錄下來,并且要記錄SessionID、Session值、所在頁面、當前函數、函數中的第幾次Session操作,這樣找丟失的原因會方便很多
3. 如果允許的話,建議使用state server或sql server保存session,這樣不容易丟失
4. 在global.asa中加入代碼記錄Session的創建時間和結束時間,超時造成的Session丟失是可以在SessionEnd中記錄下來的。
5. 如果有些代碼中使用客戶端腳本,如javascript維護Session狀態,就要嘗試調試腳本,是不是因為腳本錯誤引起Session丟失。
?
轉(3):Session丟失原因與解決方案小結
可能的原因1:
win2003 server下的IIS6默認設置下對每個運行在默認應用池中的工作者進程都會經過20多個小時后自動回收該進程,造成保存在該進程中的session丟失。
因為Session,Application等數據默認保存在運行該Web應用程序的工作者進程中,如果回收工作者進程,則會造成丟失。
解決辦法:
修改配置,設置為不定時自動回收該工作者進程,比如設置為當超出占用現有物理內存60%后自動回收該進程。通過使用默認應用程序池,可以確保多個應用程序間互相隔離,保證由于一個應用程序的崩潰不會影響另外的Web應用程序。還可以使一個獨立的應用程序運行在一個指定的用戶帳號特權之下。如果使用StateServer方式或者Sql Server數據庫方式來保存Session,則不受該設置的影響。
可能的原因2:
系統要運行在負載平衡的 Web 場環境中,而系統配置文件web.config中的Session狀態卻設置為InProc(即在本地存儲會話狀態),導至在用戶訪問量大時,Session常經超時的情況。引起這個現象的原因主要是因為用戶通過負載平衡IP來訪問WEB應用系統,某段時候在某臺服務器保存了Session的會話狀態,但在其它的WEB前端服務器中卻沒有保存Session的會話狀態,而隨著并發量的增大,負載平衡會當作路由隨時訪問空閑的服務器,結果空閑的服務器并沒有之前保存的Session會話狀態。
解決辦法:?
1.當您在負載平衡的 Web 場環境中運行 ASP.NET Web 應用程序時,一定要使用 SqlServer 或 StateServer 會話狀態模式,在項目中我們基于性能考慮并沒有選擇SqlServer模式來存儲Session狀態,而是選擇一臺SessionStateServer 服務器來用戶的Session會話狀態。我們要在系統配置文件web.config中設置如下:?
<sessionState
mode="StateServer" cookieless="false" timeout="240"
stateConnectionString="tcpip=192.168.0.1:42424" stateNetworkTimeout="14400" />
還要添加一項?
<machineKey
validationKey="78AE3850338BFADCE59D8DDF58C9E4518E7510149C46142D7AAD7F1AD49D95D4" decryptionKey="5FC88DFC24EA123C" validation="SHA1"/> ?
2. 我們同時還要在SessionStateServer 服務器中啟動ASP.NET State Service服務,具體設置:控制面板>>管理工具>>服務>>ASP.NET State Service,把它設為自動啟動即可。?
3. 每臺前端WEB服務的Microsoft“Internet 信息服務”(IIS)設置?
? ? ? ? ? ? ?要在 Web 場中的不同 Web 服務器間維護會話狀態,Microsoft“Internet 信息服務”(IIS) 配置數據庫中 Web 站點的應用程序路徑(例如,/LM/W3SVC/2)與 Web 場中所有 Web 服務器必須相同。大小寫也必須相同,因為應用程序路徑是區分大小寫的。在一臺 Web 服務器上,承載 ASP.NET應用程序的 Web 站點的實例 ID 可能是 2(其中應用程序路徑是 /LM/W3SVC/2)。在另一臺 Web 服務器上,Web 站點的實例 ID 可能是 3(其中應用程序路徑是 /LM/W3SVC/3)。因此,Web 場中的 Web 服務器之間的應用程序路徑是不同的。我們必須使Web 場Web 站點的實例 ID 相同即可。你可以在IIS中把某一個WEB配置信息保存為一個文件,其他Web 服務器的IIS配置可以來自這一個文件。您如果想知道具體的設置請訪問Microsoft Support網站:
?
轉(4):丟失問題集錦
SessionState 的Timeout),其主要原因有三種。
一:有些殺病毒軟件會去掃描您的Web.Config文件,那時Session肯定掉,這是微軟的說法。
二:程序內部里有讓Session掉失的代碼,及服務器內存不足產生的。
三:程序有框架頁面和跨域情況。
第一種解決辦法是:使殺病毒軟件屏蔽掃描Web.Config文件(程序運行時自己也不要去編輯它)
第二種是檢查代碼有無Session.Abandon()之類的。
第三種是在Window服務中將ASP.NET State Service 啟動。
http://community.csdn.net/Expert/topic/3100/3100218.xml?temp=.4426386
還有可能就是你在測試期間改動了,網站的文件。
下面是幫助中的內容:
(ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.2052/cpguide/html/cpconsessionstate.htm)
ASP.NET 提供一個簡單、易于使用的會話狀態模型,您可以使用該模型跨多個 Web 請求存儲任意數據和對象。
它使用基于字典的、內存中的對象引用(這些對象引用存在于 IIS 進程中)緩存來完成該操作。
使用進程內會話狀態模式時請考慮下面的限制:
使用進程內會話狀態模式時,如果 aspnet_wp.exe 或應用程序域重新啟動,則會話狀態數據將丟失。這些重新啟動通常會在下面的情況中發生:
(1)在應用程序的 Web.config 文件的 <processModel> 元素中,設置一個導致新進程在條件被滿足時啟動的屬性,例如 memoryLimit。
(2)修改 Global.asax 或 Web.config 文件。
(3)更改到 Web 應用程序的 /Bin 目錄。
(4)用殺毒軟件掃描并修改 Global.asax 文件、Web.config 文件或 Web 應用程序的 /Bin 目錄下的文件。
(5)如果在應用程序的 Web.config 文件的 <processModel> 元素中啟用了網絡園模式,請不要使用進程內會話狀態模式。否則將發生隨機數據丟失。
?
我也碰到過。本機器上的Session或者Cookie丟失。
<sessionState
mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="40"
/>
mode=""的三個屬性。本地/其他機器/sqlserver。
很多網絡架構,各個服務器之間都是通過一臺專門保存狀態的服務器(專門的狀態服務器)來保存比如說session,cookie..
?
我以前遇到這種問題,我用了以下幾個方法來解決。現在也沒有這種情況發生了。
1、release,不要debug發布。
2、<sessionState cookieless="true" 把cookieless設為true。因為客戶端禁用cookie時,session也無效。
3、在IIS中把Session過期時間延長。
4、讓殺毒軟件不掃描bin文件夾下的文件和Web.Config文件。
以上我是不明不白的做的。不過Session正常使用了!呵呵~~我幸運!
?
沒啥好講的,不要用Session好了,直接用Forms認證把,
我前兩天的系統就是用這個搞定的,覺得挺好的。
剛碰到一個類似的問題:在使用frameset的時候,session變量丟失。
在微軟的網站上找到了解決的方法
http://support.microsoft.com/kb/323752/EN-US/
不知道是否有用?
IIS--->>應用程序連接池--->>屬性---->>[回收][性能][運行狀況]里的各項參數盡量都往大的改^_^),我不知道改拉那個才對的,反正我改完后所有的session都好拉.客戶的網站和動網論壇的后臺也跟著好拉。
?
轉(5): 模態窗口中打開新窗口的session丟失
? ? ? ? ?一直被這個問題郁悶。在窗口A中使用showModalDialog()打開了一個新的模態窗口B。然后在B窗口中進行一些業務操作,最后還需要根據業務操作打印一些表單,結果此時在B中調用open()方法就會出現session丟失的現象,提示用戶重新登陸。
? ? ? ? ?兩天來一直沒頭蒼蠅一樣不停的試驗各種方法。如果在這個窗口中采用打開非模態對話框的打開方法showModelessDialog()就沒有任何問題,但是直接使用open()方法就是不能達到想要的效果。在網上不停的google,到各大bbs尋找解答,提供的都是最簡單的應用。好不容易找到一篇文章,其中提到session對象的有效范圍,卻也沒有具體提到我遇到的問題:
IE中:
有效的窗品包括
? ? ? ? ?1.Session對象只在建立Session對象的窗口中有效。
? ? ? ? ?2.在建立Session對象的窗口中新開鏈接的窗口
無效的窗口包括
? ? ? ? ?1.直接啟動IE瀏覽器的窗口
? ? ? ? ?2.不是在建立Session對象的窗口中新開鏈接的窗口。(即作者在建立Session對象的A窗口彈出的B窗口上調用了open()方法。)
考慮只在建立session對象的窗口中有效,于是就在子窗口中重新使用session.setAttribute()方法,以為如此就可以成功,結果還是不行,郁悶。
? ? ? ? ?早上起來突然來了靈感,既然子窗口中造成了session丟失,在父窗口中是無論如何還存在著session的變量的,我可以不必在子窗口中重新設置session變量,而可以直接調用父窗口的javascript函數open()方法可能會到目的吧。不管如何先試試,結果果然如此。 ? ? ?很多時候問題就是這樣的,想要偷懶,于是不自己鉆研,到處尋求解答,最后還是得靠自己來搞定。
========
ASP.NET一般處理程序訪問Session問題
https://www.cnblogs.com/yunfeifei/p/3674832.html
我們在使用一般處理程序的時候,訪問Session會出現如下錯誤:
解決方案如下:
//引用命名空間
using System.Web.SessionState;
//繼承IRequiresSessionState接口,擁有Session的讀寫權限
//繼承IReadOnlySessionState接口,擁有Session的只讀權限
public class Handler1 : IHttpHandler,IRequiresSessionState
? ? {
? ? ? ? public void ProcessRequest(HttpContext context)
? ? ? ? {
? ? ? ? ? ? context.Response.ContentType = "text/plain";
? ? ? ? ? ? context.Response.Write("Hello World");
? ? ? ? }
? ? ? ? public bool IsReusable
? ? ? ? {
? ? ? ? ? ? get
? ? ? ? ? ? {
? ? ? ? ? ? ? ? return false;
? ? ? ? ? ? }
? ? ? ? }
? ? }
========
?
總結
以上是生活随笔為你收集整理的Asp.Net Session学习总结的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: VC++ 单文档项目显示打开的文件
- 下一篇: EasyUI Window学习总结