Несмотря на то, что необходимо свести к минимуму влияние на транзакции и обеспечение непредвиденного в распределенных транзакциях, в этом примере действительно нет необходимости заново изобретать IIS только потому, что процесс долго выполняется. Весь мем "IIS может умереть в любой момент" ИМХО сильно преувеличен.
Да, вы можете вручную перезапустить IIS или пул приложений, но вы можете перезапустить любую другую службу, которая выполняет ту же работу для того же эффекта. Что касается автоматического повторного использования, IIS использует перекрывающиеся рабочие процессы и никогда не завершит принудительно завершенный поток (если не истекло время ожидания). Если бы это было так, у нас были бы серьезные проблемы с любым размещенным приложением (что мешает IIS уничтожить поток быстрого ответа через 0,001 мс после запуска)
По сути, позвольте IIS делать то, что IIS делает лучше всего, и не настаивать на операции синхронизации, вы просто потеряете поток пула, ожидая блокировки ввода-вывода, чего, я полагаю, вы пытаетесь избежать. Вы уже сделали хороший выбор, перейдя в Asynchronous Handlers (ASHX), используя реализацию IHttpAsyncHandler, чтобы создать свой собственный поток, который будет блокироваться по вашему желанию, не затрагивая веб-приложение и его пул. Как только вы инициируете поток асинхронной операции, поток asp.net вернется в свой собственный пул и будет готов начать обслуживание нового запроса. С ограничением по умолчанию в 100 потоков в пуле и с учетом того, что ваш процесс имеет низкую скорость процессора и высокую пропускную способность, я не сомневаюсь, что у вас никогда не кончатся потоки пула, прежде чем закончится пространство канала :). Для получения дополнительной информации о том, как построить асинхронный обработчик, проверьте эту ссылку (это старая статья, но действительная, тем не менее):
Использование потоков и создание асинхронных обработчиков в веб-коде на стороне сервера