Вы пишете надежный управляемый код? Очевидно, что когда задается такой вопрос, хочется ответить «да». Вы используете блоки try/finally для предопределенного высвобождения ресурсов и активно применяете самоочищаемые объекты. Поэтому, конечно, ваш код надежен, верно? Работа выполнена на отлично?
Как ни печально, но это еще не все. В контексте написания управляемого кода надежность предполагает возможность выполнения последовательности предопределенных действий даже в условиях исключительной ситуации. Это позволяет гарантировать отсутствие утечек ресурсов и возможность управления стабильностью состояния и не полагаться на выгрузку домена приложения (или еще хуже, на перезапуски процесса) при выходе из любого состояния нарушения информации. К сожалению, в Microsoft® .NET Framework не все исключения являются предопределенными и синхронными, что усложняет задачу по написанию кода, абсолютно детерминированного в его способности выполнять предопределенную последовательность операций. А в .NET Framework 1.x некоторые ситуации делают это практически невозможным. В данной статье я покажу, почему это происходит, и затем рассмотрю новые возможности .NET Framework 2.0, помогающие смягчать эти ситуации и писать более надежный код.
Основной пример, почему это важно: начиная с версии SQL Server™ 2005, SQL Server может размещать общеязыковую среду выполнения (common language runtime – CLR), что позволяет использование в управляемом коде хранимых процедур, функций и триггеров. Поскольку доступ к хранимым процедурам должен быть быстрым, CLR встраивается в процесс SQL Server. Для обеспечения высокой работоспособности ASP.NET применяет повторное использование процессов: при выявлении некорректного функционирования текущих рабочих процессов запускаются новые рабочие процессы. Но SQL Server с его внутрипроцессным размещением не располагает такой роскошью; он не может просто перезапустить рабочий процесс, поскольку при перезапуске этого основного процесса базы данных возникнет простой. Поэтому в качестве защиты от непрогнозируемых сбоев SQL Server выбирает изоляцию домена приложения, чтобы можно было просто выгрузить домен приложения с ухудшающимися характеристиками и заменить новой. Поэтому крайне важно, чтобы код, выполняющийся на SQL Server, был максимально надежным, и чтобы в случае нарушения общего состояния это нарушение было изолированным, и сервер мог восстановиться. (Повреждение всего процесса может заставить SQL Server отключить CLR.) Надежность важна для клиентских приложений, которые потребляют системные ресурсы, и она исключительно важна для любого приложения, к которому предъявляется требование обеспечения большого периода работоспособности, будь то SQL Server, служба Windows® или любой другой хост или приложение, которому может понадобится выполняться в течение длительных промежутков времени. Обеспечение надежности своего кода является огромным шагом на пути к возможности выполнения в этих средах.