Made Simple to understand App Pool and App Domain
14:27:00App Pool, App Domain and their importance App Domain provides a major use of isolating processes. These are used for running dif...
14:27:00
App Pool, App Domain and their importance
App Domain provides a major use of isolating processes. These are used for running different versions of assemblies, run code with specific trust levels, rectify problems without effecting other applications . These are lightweight processes whose characteristics are almost same as a process as they have their own assemblies but all of these are contained with in a single process. In the context of the operating system a process is a single executable program and it doesn't matter if it has got single or multiple AppDomain’s. Unlike a process however, an AppDomain does not have any threads unless you explicitly create them. A thread can run code in any AppDomain.
As AppDomains are part of the same process and thus actually share the same managed heap. This is usually not an issue since the AppDomain programming model prevents implicit access between AppDomains. However, some references are actually shared between AppDomains such as type objects and interned strings. That is AppDomain's cannot directly reference contents in another. Data must be passed between AppDomains through a copy-by-value process. In particular, reference objects, which rely on pointers and therefore memory addresses, must be first serialised from then deserialisation into the source and destination AppDomain, respectively.
Memory boundaries were implemented by processes; however, on Windows systems constructing processes is resource intensive. They also serve a dual purpose as thread boundaries. App-domains are concerned only with memory boundary or address space. Threads can 'flow' across AppDomains (that is a procedure can invoke an entry point in another AppDomain and wait for it to return at which point the thread is said to continue execution within the other AppDomain).
One significant benefit is that the communication pattern between App-domains remain substantially unchanged whether the AppDomains are in the same process, different processes, or on different machines all together: namely serialisation and deserialisation.
Note 1: the meaning of a thread crossing an AppDomain is that of a blocking or synchronous method call into another AppDomain (versus a non-blocking or asynchronous call which continues without waiting for a response).
Note 2: there is such a thing as Thread Local Storage. However, a better name would have been App-Domain Thread Local Storage since threads leave their data behind as they cross App-Domains but pick them back up when they return: http://msdn.microsoft.com/en-us/library/6sby1byh.aspx
An Application pool separates web applications on a server so it behaves completely independent of the other web applications, so if an web application fails it wont effect other applications as it it is already isolated. Each application domain has its own virtual address space which scopes the resources for the application domain using that address space. The worker process basically processes all the requests for a web application. One application pool uses one worker process by default but it can use more. In process explorer it will display as W3wp.exe. Every application pool in IIS use it's own process. Different applications in Asp.net will use different AppDomain. Applications can be in different AppDomain's, but they exist same process.
Application pool and App-domain, both of them can provide isolation's, but use different approaches. Application pool uses the process to isolate the applications which works without .NET. But App-domain is another isolation methods provided by .NET. If your server host thousands of web sites, you wont create thousands of the application pool's to isolate the web sites, because, too many processes running will kill the OS. However, sometime you need application pool. One of the advantages for application pool is that you can configure the identity for application pool. Also you have more flexible options to recycle the application pool. At least right now, IIS didn't provide explicit options to recycle the app-domain. If you only have a single site in your app pool, then an app pool and an App-domain recycle will be quite similar. The app pool recycle will recycle the entire W3wp.exe process while the App-domain will recycle the .NET App-domain only, but since most of what that needs to be recycled lives in the App-domain, they will achieve the same thing. It's just a matter of which is easier for you to do. But, if the App-domain recycle doesn't do the trick, then try a full app pool recycle. This will depend on your situation. If you have multiple sites in the app pool, then an App-domain is preferred because it won't touch any of the other sites or applications in the app pool and is isolated to just the single application/App-domain in the app pool.
To keep it simple and easy to remember go through the differences listed out between app-domain and application pool :
- Basically, an Application is an IIS term, which will create a sandbox, or a set of boundaries in order to separate different sites, or parts of sites, from the others.
- AppDomain is a .NET term, which contains InProc session state so that if an AppDomain is killed or recycled, all of your session state information will be lost.
- Applications can have multiple AppDomains in them, although most of the time there is a one-to-one relationship between them.
- In IIS6 and greater, there is the option of creating groups or "pools" of applications that can be bundled together or separated, however, it will decide by server administer. These are called Application Pools. Each application pool runs under its own W3wp.exe worker process.
- In IIS, it is easy to see an application. A new website is a separate application and any sub-folder can be marked as an application. When they are, the icon beside the folder turns into a picture of some gears. By right-clicking on the folder, you have the option of marking a folder as an application or removing it as an application, if it already is one. Also, in IIS6, in the Application Pools section, you can see all of the applications and which application pool they live under.
- On the other hand, ASP.NET does not give much visibility into AppDomains, at least not from any visual tools. This is done behind the scenes. Programmatically, you can create them, tear them down or see a list of all running AppDomains.
- You can recycle an application from IIS. In IIS5, you cannot do it directly unless you recycle the entire web server, but in IIS6 and greater, you can recycle the application pool that the application lives under. It will gracefully die off and a new application will start up to replace it. Or, to word it another way, another W3wp.exe worker process will be started and then the old one will die off after it completes any currently running page requests.
- You can recycle an AppDomain in ASP.NET through the "touch trick". There are some ways to do it, but the most straightforward is to edit your web.config file in notepad and add a space to an insignificant place. Then save the file. This will cause the AppDomain to recycle. This does not touch the IIS application though.
- Recycling an AppDomain will come pretty close to starting ASP.NET freshly again for that particular ASP.NET application, so although it does not recycle the application pool, it can give ASP.NET a fresh start in many situations.
Also, consider learning about In-Proc & Out-Proc as they are equally important
InProc Session State
InProc session mode indicates that session state is stored locally. This means that with InProc session state mode is actually stored as life objects in the AppDomain of the Web application. This is why the session state is lost when Aspnet_wp.exe or W3wp.exe or the AppDomain restarts.
Session Data Is Lost When You Use ASP.NET InProc Session State Mode. Session state data is lost if the AppDomain or the Aspnet_wp.exe process or W3wp.exe is recycled. Generally, the AppDomain is restarted based on several factors, couple of them are :
- The Global.asax or the Web.config file was modified.
- The Bin directory of the Web application was modified.
To work around this problem, you can use StateServer or SqlServer session state mode. ASP.NET provides these other approaches for storing session state data. In the StateServer and SqlServer modes, your session state is not stored in the AppDomain of the Web application.
OutProc Session State
In OutProc Session, Session State is stored In the StateServer and SqlServer modes, your session state is not stored in the AppDomain of the Web application.
1. StateServer: Alternately, StateServer mode uses a stand-alone Microsoft Windows service to store session variables. Because this service is independent of Microsoft Internet Information Server (IIS), it can run on a separate server. You can use this mode for a load-balancing solution because multiple Web servers can share session variables. Although session variables are not lost if you restart IIS, performance is impacted when you cross process boundaries.
2. SqlServer: If you are greatly concerned about the persistence of session information, you can use SqlServer mode to leverage Microsoft SQL Server to ensure the highest level of reliability. SqlServer mode is similar to out-of-process mode, except that the session data is maintained in a SQL Server. SqlServer mode also enables you to utilise a state store that is located out of the IIS process and that can be located on the local computer or a remote server.
Dedicated To Web Technology Enthusiasts and thanks to all peers whose knowledge shared over media helped me put together all the important points.
