транзакции. Этот процесс описывается так называемым двух-фазным протоколом завершения транзакции.

На первой фазе менеджер транзакций просит всех менеджеров ресурсов подготовиться к завершению транзакции. Подготовка состоит в сохранении результатов транзакции в форме, которая может пережить программный или технический сбой (запись в файл). Заметим, что при этом результаты транзакции еще не публикуются, т. е., например, не заносятся в базу данных. При успешном завершении фазы подготовки менеджер ресурса уведомляет об этом менеджера транзакций.

Во второй фазе менеджер транзакций принимает окончательное решение об успешном завершении транзакции или об откате назад.

Если все зарагистрированные в транзакции менеджеры ресурсов подтвердили успешное завершение первой фазы, то менеджер транзакций дает команду на внесение результатов транзакции во все базы данных. При этом он уже не ждет подтверждений от менеджеров ресурсов. Если во время выполнения второй фазы в каком-либо из ресурсов данных произошел сбой, то после восстановления его работоспособности менеджер ресурса завершает обновление данных самостоятельно. Если из-за сбоя он не получил команды от менеджера транзакций, он обращается к менеджеру транзакций с просьбой повторить эту команду.

Если кто-то из менеджеров ресурсов не смог завершить успешно (или вовремя) фазу подготовки, менеджер транзакций выдает команду на откат назад.

Теперь опишем процесс порождения, распространения и завершения распределенной транзакции в целом. Остановимся на случае декларативной демаркации транзакции, т. к. именно этот способ используется в СОМ+.

1. Порождение транзакции

Новая транзакция порождается при активации некоторого прикладного компонента. Данный прикладной компонент либо требует порождения новой транзакции не зависимо от наличия транзакции, в которой выполняется его активатор, либо ему требуется какая-либо транзакция, но активатор выполняется вне транзакций.

Порождается транзакция менеджером транзакций, который формирует контекст транзакции, делая его доступным для данного прикладного компонента.

В соответствии с декларативным принципом демаркации транзакции, все операции, выполняемые данным прикладным компонентом, принадлежат этой транзакции.

2. Распространение транзакции

Если прикладной компонент, выполняющийся в некоторой транзакции, инициирует активацию нового прикладного компонента, то этот компонент помещается в текущую транзакцию если он не требует явно выполнения в новой транзакции или выполнения вне всякой транзакции. Контекст текущей транзакции становится доступным вновь включенному в транзакцию компоненту.

Если прикладной компонент, выполняющийся в некоторой транзакции, обращается к некоторому ресурсу данных, для которого имеется менеджер ресурса, то последний регистрируется у менеджера транзакций для участия в текущей транзакции (если такая регистрация не была выполнена ранее).

Прикладные компоненты не заботятся о том, чтобы транзакция удовлетворяла ACID свойствам. Эта ответственность возложена на менеджера транзакций и менеджеров ресурсов, вовлеченных в текущую транзакцию.

3. Завершение транзакции

Каждый прикладной компонент по завершении своей доли работ в рамках текущей транзакции информирует систему о своем согласии на успешное завершение транзакции либо о своем требовании выполнить откат назад.

Если хотя бы один прикладной компонент потребовал отката назад, менеджер транзакций выдает соответствующую команду всем зарегистрированным менеджерам ресурсов.

В противном случае, если все прикладные компоненты удовлетворены результатами транзакции, выполняется двух-фазный протокол завершения транзакции.

Далее мы перейдем к рассмотрению того, как распределенные транзакции реализованы в СОМ+. Но предварительно уместно остановиться на вопросе совместимости менеджеров транзакций и менеджеров ресурсов от различных поставщиков. Очевидно, что при работе на платформе СОМ+ разработчик будет использовать менеджер транзакций этой платформы, который будет без проблем понимать и прикладные компоненты, созданные на этой платформе. Несомненно, этот менеджер транзакций способен регистрировать для участия в транзакции менеджеров ресурсов, разработанных в Microsoft. Это Microsoft SQL Server, Microsoft Message Queue Server. Но как быть с менеджерами транзакций от других поставщиков?

Имеется стандарт X/Open Distributed Transaction Model от консорциума Open Group. Эта модель специфицирует несколько интерфейсов, среди которых два описывают взаимодействие между прикладными компонентами, менеджером транзакций и менеджерами ресурсов:

• ТХ интерфейс

Данный интерфейс реализуется менеджером транзакций и используется прикладными компонентами при формировании транзакции, информировании менеджера транзакций о согласии данного компонента завершить текущую транзакцию успешно или о требовании выполнить откат и т. п.

• ХА интерфейс

Этот двунаправленный интерфейс обеспечивает взаимодействие менеджера транзакций и менеджера ресурсов. Часть функций данного интерфейса реализуется менеджером ресурсов, а часть — менеджером транзакций. В частности, менеджер транзакций реализует функции регистрации и дерегистрации менеджера ресурсов для участия в транзакции.

Для совместимости менеджера транзакций из СОМ+ с менеджерами ресурсов от других поставщиков в СОМ+ предусмотрена поддержка ХА интерфейса. В результате в распределенную транзакцию, порожденную прикладными компонентами выполняющимися под СОМ+, могут быть вовлечены менеджеры ресурсов для таких систем хранения данных как Oracle, Informix, IBM DB2, Sybase SQL Server, Ingres, выполняющихся на различных платформах.

Теперь перейдем непосредственно к транзакционной модели, реализованной в СОМ+.

Модель транзакций в СОМ+

Прикладные компоненты

Начнем с прикладных компонентов. В СОМ+ прикладным компонентом является экземпляр конфигурированного класса, который должен быть описан определенным набором атрибутов. Связанные с транзакциями атрибуты и их возможные значения будут приведены далее.

Прежде всего участие или неучастие объекта в транзакции определяется его транзакционным атрибутом. Значение этого атрибута может быть задано как разработчиком класса (в IDL файле, содержащем описание данного класса), так и администратором (посредством использования Component Services).

Для задания этого атрибута посредством IDL файла достаточно включить одно из возможных его значение в список атрибутов, предваряющий описание соответствующего класса.

Указанный атрибут после компиляции IDL файла будет храниться в библиотеке типов.

При использовании Component Services необходимое значение атрибута задается на вкладке Transactions.

Транзакционный атрибут может принимать одно из пяти значений (ниже эти значения приведены в той форме, которая используется в Components Services):

• Disabled

Выбор этого значения отключает автоматическое управление транзакциями для всех экземпляров данного класса. Разработчик должен самостоятельно реализовать взаимодействие объекта с менеджером транзакций для обеспечения, например, некоторого нестандартного поведения объекта.

• Not Supported

Объект, которому приписано это значение, не только сам отказывается участвовать в каких-либо транзакциях, но и не распространяет транзакцию на объекты, активацию которых он инициирует. Иными словами, пусть объект А выполняется в транзакции Т1, объект В активируется объектом А и имеет Not supported в качестве значения транзакционного атрибута. Пусть, наконец, объект С активируется объектом В. Тогда, не зависимо от значения транзакционного параметра, приписанного объекту С, данный объект не будет выполняться в транзакции Т1.

• Supported

Объект с таким значением транзакционного атрибута согласен на все. Если его активировал объект, выполняющийся в некоторой транзакции, то он будет выполняться в той же транзакции. Если активатор вне транзакций, то и активированный объект вне транзакций.

• Required

При выборе этого значения мы получаем объект, который всегда выполняется в контексте некоторой транзакции. Если его активатор уже принадлежит некоторой транзакции, то и он принадлежит той же транзакции. В противном случае при активации объекта