使用 IIS 5.0 时，如果一个运行于低隔离模式或运行于中隔离模式的 Web 网站发生了一次失效，那么重启网站的唯一方法就是重启整个 IIS。这样做会导致 IIS 突然停止服务，所以，在重启过程中到达的请求都将发生失效。
IIS 6.0 引入了一种革命性的概念，即重叠处理的概念。基于重叠处理的概念，即使一个应用程序池被回收，所有后来到达的请求仍然可以继续得到服务。IIS 7.0 仍然支持这个概念。
如果某个应用程序池被回收，那么现有的工作进程并没有马上退出，而是启动第二个工作进程，一旦第二个进程启动成功，Http.sys 随即将所有的新的请求发送给这个新的工作进程。当现有的工作进程处理完所有请求之后即关闭退出。因为 Http.sys 可以在将到达的请求发送给新的工作进程之前，完成对已到达的请求进行排队处理的操作，因此，在回收应用程序池的过程中，不会发生丢失页面请求的现象。
尽管在回收应用程序池的过程中不会发生页面请求丢失现象，也不会出现页面请求发生失效的情况，但是对回收过程而言，确实可能存在不良影响，这是因为在回收应用程序池的过程中，所有保存在工作进程中的数据都将丢失。默认情况下，ASP.NET 保存了会话状态数据和进程内缓存数据（我们称之为 InProc 数据）。这些数据的有效时间与工作进程的存活时间完全相同，因此在回收应用程序池的过程中，必须重新创建这些数据。所以，必须考虑在进程外保存会话状态数据。可以在 StateServer、SQLServer，或其他外部会话状态存储区中保存会话状态数据。此外，当启动一个新的工作进程时，可能会发生加载性能问题。此时，IIS 和 ASP.NET 的各个方面内容都必须加载到工作进程中，因此总的来说加载时间还是比较长的，常常需要耗费几秒钟的时间。因此，与应用程序池正常运行情况相比，应用程序池回收之后运行的第一个页面常常要花费更多时间才能正常运行。