整理兩個容易混淆的概念：Application Pool 和 Application Domain。
App domain 是 .NET framework 的應用程式隔離單位，app pool 則是 IIS 管理 web 應用程式的機制。你可以透過 app pool 的設定來控制 ASP.NET 應用程式所要使用的 .NET 版本、碰到哪些情況要自動重新啟動等等。
兩者的關係（或差異）是，一個 app pool 可以「管轄」多個 web 應用程式，而每一個 web 應用程式通常只有一個 app domain。
App domain 是 .NET framework 的應用程式隔離單位，app pool 則是 IIS 管理 web 應用程式的機制。你可以透過 app pool 的設定來控制 ASP.NET 應用程式所要使用的 .NET 版本、碰到哪些情況要自動重新啟動等等。
兩者的關係（或差異）是，一個 app pool 可以「管轄」多個 web 應用程式，而每一個 web 應用程式通常只有一個 app domain。
下圖是我的機器上的 IIS 的「ASP.NET v4.0」這個 app pool 所管轄的 web 應用程式，共有兩個：
以圖中的 DemoWeb 應用程式為例，當用戶端第一次存取 DemoWeb 時，伺服器端的 IIS 接收到用戶端的請求，便會將請求交給某個 worker process（w3wp.exe）處理。交給哪個 worker process 呢？就是 DemoWeb 所屬之 app pool（圖中的 ASP.NET v4.0）的 worker process（註：若有啟用 web garden，一個 app pool 會有多個 worker processes，參考這篇：謹慎使用 Web Garden）。
接下來，worker process 會為 DemoWeb 建立一個 app domain 來執行應用程式，以進一步處理用戶端的請求。剛才有特別提到是用戶端「第一次」存取網站，也就是說，app domain 是當用戶端對 ASP.NET 應用程式發出第一個請求時才建立起來的（ lazy initialization）。
那麼，每當 web.config 有變動時，是回收 app pool，還是 app domain？
每當網站應用程式有下列變動：
- web.config 更新了
- 網站中的任何網頁程式更新了
- 網站中的 DLL 檔案更新了
ASP.NET 執行環境就會建立一個新的 app domain，讓後續的請求由這個新的 app domain 負責處理。至於原本還在佇列中等候的請求，就還是由舊的 app domain 繼續處理，直到這些既有請求都處理完畢之後，ASP.NET 就會將它釋放掉。也就是因為 ASP.NET 有這種機制，我們才可以在不重啟 IIS 的情況下，隨時更新火線作業中的網頁程式，而不至於影響既有的用戶端。
至於 app pool，則是從 IIS 來設定回收的時機。當 app pool 回收時，IIS 也會先建立新的 worker process，然後將原先的 worker process 結束掉（你可以在手動回收 app pool 時，利用工作管理員觀察 w3wp.exe 的變化）。當然，worker process 一結束，其中的 app domain 也就結束了，在那個 app domain 當中執行的 ASP.NET 應用程式也就結束了，in-process session 的狀態資料亦隨之消失。那....如果是 out-of-process 的 session 呢？還在！（謎之音：會不會太複雜啊 >_<|||）
沒有留言: