Интернет-журнал 'Домашняя лаборатория', 2007 №6 - Вязовский

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

• 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 о своем отношении к текущей транзакции. Эти биты иногда называют бит голосования и бит деактивации по возврату.

• Бит голосования

Принимает значение 1, если объект в данный момент удовлетворен ходом дел и собирается голосовать за успешное завершение транзакции если ничего не изменится.

По умолчанию именно это значение выбирается при активации объекта.

Принимает значение 0, если объект в данный момент не удовлетворен результатами и собирается голосовать за откат назад.

• Бит деактивации по возврату

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

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

Для модификации указанных битов имеется несколько возможностей. Рассмотрим одну из них. Интерфейс IObjectContext объекта контекста имеет четыре метода, которые можно использовать для задания значений этих битов (см. таблицу 3.2)

Заметим, что