Monday, July 6, 2009

Applications Pools vs Application Domains

Many people are puzzled when they're asked this question about the difference between application pools and application domains. Although there is no direct comparison between these two but they provide almost the same functionality (though at different layers/levels) i.e. Isolation between applications. After reading this article one would be comfortable with the two terms: Application Pool and Application Domain. To start with let's discuss Application Domains.

Application Domains

An AppDomain is a .NET term (In IIS7, AppDomains play a larger role within IIS, but for the most part it's an ASP.NET term). Historically, process boundaries have been used to isolate applications running on the same computer. Each application is loaded into a separate process, which isolates the application from other applications running on the same computer. The applications are isolated because memory addresses are process-relative; a memory pointer passed from one process to another cannot be used in any meaningful way in the target process. In addition, you cannot make direct calls between two processes. Application domains provide a more secure and versatile unit of processing that the common language runtime can use to provide isolation between applications. You can run several application domains in a single process with the same level of isolation that would exist in separate processes, but without incurring the additional overhead of making cross-process calls or switching between processes. An AppDomain contains InProc session state (the default session state mode). So if an AppDomain is killed/recycled, all of your session state information will be lost. (if you are using the default InProc session state). Applications can have multiple AppDomains in them although often times there is a one-to-one relationship between them. You can recycle an AppDomain in ASP.NET through the 'touch trick'. There are a few ways to do it, but the most straight forward 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 fresh again for that particular ASP.NET application, so although it doesn't recycle the apppool, it can give ASP.NET a fresh start in many situations.

The ability to run multiple applications within a single process dramatically increases server scalability. The isolation provided by application domains has the following benefits:

  • Faults in one application cannot affect other applications. Because type-safe code cannot cause memory faults, using application domains ensures that code running in one domain cannot affect other applications in the process.
  • Individual applications can be stopped without stopping the entire process. Using application domains enables you to unload the code running in a single application.
    Code running in one application cannot directly access code or resources from another application.
  • Permissions granted to code can be controlled by the application domain in which the code is running.
  • Isolating applications is also important for application security. For example, you can run controls from several Web applications in a single browser process in such a way that the controls cannot access each other's data and resources.

Now lets have a look at Application Pools.

Application Pools

Application pools is another way of isolation applications but on an IIS level. When you run IIS 6.0 in worker process isolation mode, you can separate different Web applications and Web sites into groups known as application pools. An application pool is a group of one or more URLs that are served by a worker process or set of worker processes. Any Web directory or virtual directory can be assigned to an application pool.
Every application within an application pool shares the same worker process. Because each worker process operates as a separate instance of the worker process executable, W3wp.exe, the worker process that services one application pool is separated from the worker process that services another. Each separate worker process provides a process boundary so that when an application is assigned to one application pool, problems in other application pools do not affect the application. This ensures that if a worker process fails, it does not affect the applications running in other application pools. Application pools, then, are essentially worker process configurations that service groups of namespaces.
Multiple application pools can operate at the same time. An application, as defined by its URL, can only be served by one application pool at any time. While one application pool is servicing a request, you cannot route the request to another application pool. However, you can assign applications to another application pool while the server is running.

1 comment: