Enterprise Services (COM+) Administration: Application Pooling and Recycling
Pooling and recycling services are available only for a server application. You cannot configure library applications to use pooling and recycling since they do not own their hosting process. Library applications have, in effect, the pooling and recycling parameters of whichever server application happens to load them.
Application pooling
Application pooling allows you to configure the number of surrogate processes launched to host your application's components.
COM+ gives you explicit control over how many processes are launched by configuring a process pool. You configure the pool size in the Pool size edit box. The default pool size is 1, that means a single process hosts all instances of components from the application.
If you set it to a value greater than 1, COM+ creates a process for each new instance until it reaches the pool size, at which point COM+ starts multiplexing new instances to the existing processes in a round-robin fashion. The maximum configurable pool size is 999,999.
Application pooling is very helpful as a fault solving technique. If one process has to shut down because of a fault or exception, the other processes and their clients will not have a problem. Application pooling also gives you same-computer load balancing. You do not have to use a separate load balancing service and multiple computers to allocate different instances to different processes by COM+
Application recycling
Application recycling is used to increase overall application robustness and availability by compensating for code defects. For example, one of the most common defects is a memory leak. Even a very small memory leak can have a devastating effect over a long period of time. For example, imagine a system with an "insignificant" memory leak of only 10 bytes per method call. A modern system that processes in excess of 100 method calls per second will, after one day, leak 100MB of memory.
To cope with memory leaks, you can have COM+ terminate the process when it reaches a memory limit (see the Memory Limit edit box in the above figure). A value of zero (no limit) is the default value.
To cope with defects in handling other kinds of resources (such as system handles), you can instruct COM+ to shut down your application after a predetermined amount of time by specifying the Lifetime Limit value. A value of zero (no lifetime limit) is the default value.
You can have COM+ recycle your application after a specified number of method calls into your application by specifying such a limit in the Call Limit edit box. The number of calls is defined as the combined number of calls made on all the objects in the application. The default value is set to zero (no limit).
You can also request application recycling after a certain number of activations. Activations are defined as the total number of objects that COM+ created in that application. You specify activation limit in the Activation Limit edit box, and again, the default value is set to zero (no limit).
Regardless of how the decision to recycle the application is made (memory limit reached, the lifetime elapsed, call or activation limit was reached), COM+ routes a new activation request to a new host process, and waits for existing clients to release their references to objects in the recycled process. However, in the Expiration Timeout edit box you can specify how long COM+ should wait. After that expiration timeout, COM+ terminates the application, even if there are still clients holding live references. The default expiration timeout is 15 minutes.
Finally, you should note that recycling is not available for a COM+ application configured as system service, nor can you recycle a paused application.