При использовании Component Services необходимое значение атрибута задается на вкладке Transactions.
Транзакционный атрибут может принимать одно из пяти значений (ниже эти значения приведены в той форме, которая используется в Components Services):
• Disabled
Выбор этого значения отключает автоматическое управление транзакциями для всех экземпляров данного класса. Разработчик должен самостоятельно реализовать взаимодействие объекта с менеджером транзакций для обеспечения, например, некоторого нестандартного поведения объекта.
• Not Supported
Объект, которому приписано это значение, не только сам отказывается участвовать в каких-либо транзакциях, но и не распространяет транзакцию на объекты, активацию которых он инициирует. Иными словами, пусть объект А выполняется в транзакции Т1, объект В активируется объектом А и имеет Not supported в качестве значения транзакционного атрибута. Пусть, наконец, объект С активируется объектом В. Тогда, не зависимо от значения транзакционного параметра, приписанного объекту С, данный объект не будет выполняться в транзакции Т1.
• Supported
Объект с таким значением транзакционного атрибута согласен на все. Если его активировал объект, выполняющийся в некоторой транзакции, то он будет выполняться в той же транзакции. Если активатор вне транзакций, то и активированный объект вне транзакций.
• Required
При выборе этого значения мы получаем объект, который всегда выполняется в контексте некоторой транзакции. Если его активатор уже принадлежит некоторой транзакции, то и он принадлежит той же транзакции. В противном случае при активации объекта порождается новая транзакция, в контексте которой и будет выполняться данный объект. Заметим, что в последнем случае этот объект называется корнем транзакции, в контексте которой он выполняется.
• Requires New
В этом случае при активации объекта всегда порождается новая транзакция, корнем которой является данный объект.
Имеется еще один атрибут, который необходимо приписать классу, собирающемуся участвовать в транзакциях. Это атрибут активация по необходимости (Just-In-Time Activation), имеющий два значения (on/off). В транзакционной модели СОМ+ все классы, которые могут выполняться в контексте какой-либо транзакции, должны быть активируемыми по необходимости (тут надо заметить, что и объекты, не собирающиеся участвовать в транзакциях, могут активироваться по необходимости).
Что такое активация по необходимости? Вспомним, как устроен жизненный цикл объекта. При создании объекта формируется счетчик числа ссылок на этот объект. Только когда значение этого счетчика станет равно нулю, объект будет уничтожен. Легко представить себе ситуацию, когда клиент инициировал формирование некоторого объекта на стороне сервера и изредка в течении нескольких часов вызывает отдельные его методы. Столь длительное присутствие этого объекта в оперативной памяти сервера приводит к излишней трате ресурсов, особенно в случае, когда данный объект удерживает дефицитное соединение с некоторой базой данных. Было бы оправдано удалять такой объект из оперативной памяти и вызывать его к жизни автоматически по мере необходимости, т. е. тогда, когда от клиента приходит новый вызов. Данный процесс и называется активацией объекта по необходимости.
При первичной активации объекта (например, клиент использует фабрику класса для построения экземпляра класса) формируется сам объект, а также прокси на стороне клиента, стаб на стороне сервера и соединяющий их канал. Пока клиент имеет хотя бы одну ссылку на данный объект, система прокси/канал/стаб продолжает существовать. Циклом же активации/деактивации объекта на стороне сервера управляет СОМ+. Объект деактивируется, если он не нужен, и активируется по необходимости. Точнее говоря, любой объект, выполняющийся в контексте некоторой транзакции, деактивируется не позднее завершения этой транзакции. Более подробно это обсуждается далее. Вторичную активацию объекта инициирует его стаб, получивший вызов от клиента.
Механизм активации по необходимости очевидно помогает решить проблему создания масштабируемого приложения. Но необходимость его использования именно в случае транзакционных объектов связана вовсе не с заботой о масштабируемости. Основная причина — повышение надежности программирования транзакционных приложений. Дело в том, что по завершении транзакции в рамках модели СОМ+ прикладные компоненты ничего не знают об окончательном ее результате — была ли транзакция успешной, либо завершилась откатом. В этих условиях опасно оставлять у прикладных компонентов, участвовавших в транзакции, какую-либо память о завершившейся транзакции. Эта память может противоречить реальному положению дел. Например, некоторый объект помнит, что счет некоторого клиента был увеличен на 100 долларов, но реально транзакция была прервана и был выполнен откат назад. В результате имеется опасность нарушения целостности данных, если упомянутый объект будет действовать далее с учетом имеющейся у него информации. Принудительная деактивация всех прикладных компонентов, участвовавших в транзакции, очищает их память, сохраняя тем самым целостность данных.
Говоря про активацию по необходимости, следует упомянуть про пул объектов. Это еще один сервис, предоставляемый СОМ+ как средство решения проблемы масштабируемости приложения. При активации объект может либо формироваться заново, либо извлекаться из пула ранее построенных объектов данного типа. При деактивизации вместо уничтожения некоторого объекта его можно вернуть в пул для последующего использования. Выбор за разработчиком.
Помещение объекта в пул и извлечение его из пула выполняется автоматически при условии, что соответствующий класс удовлетворяет ряду требований.
Прежде всего, при конфигурировании класса на вкладке Activation необходимо отметить, что экземпляры данного класса допускают помещение их в пул объектов. Здесь же задаются минимальный и максимальный размер пула. При активации приложения, содержащего данный класс, формируются экземпляры класса в числе, равном минимальному размеру пула. В дальнейшем, при активации объекта данного типа, некоторый объект извлекается из соответствующего пула или формируется новый экземпляр класса если пул пуст. Заметим, что общее число объектов данного типа не должно превышать максимальный размер соответствующего пула.
Далее приведены требования к классу, экземпляры которого можно помещать в пул:
• Класс должен реализовать стандартный интерфейс IObjectControl
Данный интерфейс имеет три метода, которые автоматически вызываются СОМ+.
♦ Activate
Этот метод вызывается автоматически при активации объекта. Здесь следует выполнить инициализацию данных объекта, получить указатель на объект контекста,
♦ Deactivate
Этот метод вызывается автоматически при деактивизации объекта. Здесь следует освободить все ресурсы, захваченные объектом,
♦ CanBePooled
Этот метод вызывается автоматически на последнем этапе деактивации. Тут объект может отказаться по каким-либо причинам от помещения в пул. В этом случае он просто будет уничтожен.
• Допустимые потоковые модели: Free, Both, Neutral
Иными словами, объект, допускающий помещение в пул, должен жить в МТА или NA апартаменте. Это связано с тем, что один поток сформирует данный объект и поместит его в пул, и совсем другому потоку понадобится извлечь его из пула и вызвать какой-либо из его методов.
• Класс должен допускать агрегацию, но сам не должен агрегировать другие помещаемые в пул объекты.
• Класс не должен использовать FTM для оптимизации маршализации указателя на интерфейс.
Распространение транзакции
Менеджер транзакций в СОМ+ имеет имя координатор распределенных транзакций — DTC (Distributed Transaction Coordinator). При активации объекта, который должен быть корнем некоторой новой транзакции, DTC порождает новую транзакцию, которая получает уникальный идентификатор (GUID). Этот идентификатор хранится к объекте контекста данного объекта. Кроме того, объект контекста хранит два бита, модифицируя которые объект информирует DTC о своем отношении к текущей транзакции. Эти биты иногда называют бит голосования и бит деактивации по возврату.