Интернет-журнал "Домашняя лаборатория", 2007 №6
Шрифт:
• ХА интерфейс
Этот двунаправленный интерфейс обеспечивает взаимодействие менеджера транзакций и менеджера ресурсов. Часть функций данного интерфейса реализуется менеджером ресурсов, а часть — менеджером транзакций. В частности, менеджер транзакций реализует функции регистрации и дерегистрации менеджера ресурсов для участия в транзакции.
Для совместимости менеджера транзакций из СОМ+ с менеджерами ресурсов от других поставщиков в СОМ+ предусмотрена поддержка ХА интерфейса. В результате в распределенную транзакцию, порожденную прикладными компонентами выполняющимися под СОМ+, могут быть вовлечены менеджеры ресурсов для таких систем хранения
Теперь перейдем непосредственно к транзакционной модели, реализованной в СОМ+.
Модель транзакций в СОМ+
Прикладные компоненты
Начнем с прикладных компонентов. В СОМ+ прикладным компонентом является экземпляр конфигурированного класса, который должен быть описан определенным набором атрибутов. Связанные с транзакциями атрибуты и их возможные значения будут приведены далее.
Прежде всего участие или неучастие объекта в транзакции определяется его транзакционным атрибутом. Значение этого атрибута может быть задано как разработчиком класса (в IDL файле, содержащем описание данного класса), так и администратором (посредством использования Component Services).
Для задания этого атрибута посредством IDL файла достаточно включить одно из возможных его значение в список атрибутов, предваряющий описание соответствующего класса.
Указанный атрибут после компиляции IDL файла будет храниться в библиотеке типов.
При использовании Component Services необходимое значение атрибута задается на вкладке Transactions.
Транзакционный атрибут может принимать одно из пяти значений (ниже эти значения приведены в той форме, которая используется в Components Services):
• Disabled
Выбор этого значения отключает автоматическое управление транзакциями для всех экземпляров данного класса. Разработчик должен самостоятельно реализовать взаимодействие объекта с менеджером транзакций для обеспечения, например, некоторого нестандартного поведения объекта.
• Not Supported
Объект, которому приписано это значение, не только сам отказывается участвовать в каких-либо транзакциях, но и не распространяет транзакцию на объекты, активацию которых он инициирует. Иными словами, пусть объект А выполняется в транзакции Т1, объект В активируется объектом А и имеет Not supported в качестве значения транзакционного атрибута. Пусть, наконец, объект С активируется объектом В. Тогда, не зависимо от значения транзакционного параметра, приписанного объекту С, данный объект не будет выполняться в транзакции Т1.
• Supported
Объект с таким значением транзакционного атрибута согласен на все. Если его активировал объект, выполняющийся в некоторой транзакции, то он будет выполняться в той же транзакции. Если активатор вне транзакций, то и активированный объект вне транзакций.
• Required
При выборе этого значения мы получаем объект, который всегда выполняется в контексте некоторой транзакции. Если его активатор уже принадлежит некоторой транзакции, то и он принадлежит той же транзакции. В противном случае при активации объекта порождается новая транзакция, в контексте которой и будет выполняться данный
• Requires New
В этом случае при активации объекта всегда порождается новая транзакция, корнем которой является данный объект.
Имеется еще один атрибут, который необходимо приписать классу, собирающемуся участвовать в транзакциях. Это атрибут активация по необходимости (Just-In-Time Activation), имеющий два значения (on/off). В транзакционной модели СОМ+ все классы, которые могут выполняться в контексте какой-либо транзакции, должны быть активируемыми по необходимости (тут надо заметить, что и объекты, не собирающиеся участвовать в транзакциях, могут активироваться по необходимости).
Что такое активация по необходимости? Вспомним, как устроен жизненный цикл объекта. При создании объекта формируется счетчик числа ссылок на этот объект. Только когда значение этого счетчика станет равно нулю, объект будет уничтожен. Легко представить себе ситуацию, когда клиент инициировал формирование некоторого объекта на стороне сервера и изредка в течении нескольких часов вызывает отдельные его методы. Столь длительное присутствие этого объекта в оперативной памяти сервера приводит к излишней трате ресурсов, особенно в случае, когда данный объект удерживает дефицитное соединение с некоторой базой данных. Было бы оправдано удалять такой объект из оперативной памяти и вызывать его к жизни автоматически по мере необходимости, т. е. тогда, когда от клиента приходит новый вызов. Данный процесс и называется активацией объекта по необходимости.
При первичной активации объекта (например, клиент использует фабрику класса для построения экземпляра класса) формируется сам объект, а также прокси на стороне клиента, стаб на стороне сервера и соединяющий их канал. Пока клиент имеет хотя бы одну ссылку на данный объект, система прокси/канал/стаб продолжает существовать. Циклом же активации/деактивации объекта на стороне сервера управляет СОМ+. Объект деактивируется, если он не нужен, и активируется по необходимости. Точнее говоря, любой объект, выполняющийся в контексте некоторой транзакции, деактивируется не позднее завершения этой транзакции. Более подробно это обсуждается далее. Вторичную активацию объекта инициирует его стаб, получивший вызов от клиента.
Механизм активации по необходимости очевидно помогает решить проблему создания масштабируемого приложения. Но необходимость его использования именно в случае транзакционных объектов связана вовсе не с заботой о масштабируемости. Основная причина — повышение надежности программирования транзакционных приложений. Дело в том, что по завершении транзакции в рамках модели СОМ+ прикладные компоненты ничего не знают об окончательном ее результате — была ли транзакция успешной, либо завершилась откатом. В этих условиях опасно оставлять у прикладных компонентов, участвовавших в транзакции, какую-либо память о завершившейся транзакции. Эта память может противоречить реальному положению дел. Например, некоторый объект помнит, что счет некоторого клиента был увеличен на 100 долларов, но реально транзакция была прервана и был выполнен откат назад. В результате имеется опасность нарушения целостности данных, если упомянутый объект будет действовать далее с учетом имеющейся у него информации. Принудительная деактивация всех прикладных компонентов, участвовавших в транзакции, очищает их память, сохраняя тем самым целостность данных.