Страница 192 из 372
3. Если ответ на предыдущий вопрос положителен, то перехват не нужен, и CoCreateInstance возвращает прямой указатель на объект.
4. В противном случае CoCreateInstance передает управление среде, совместимой с требованиями класса, создает там объект и возвращает прокси.
5. Этот прокси обеспечивает совместимость среды выполнения с требованиями класса, выполняя определенные действия до и после каждого вызова метода.
Фактически понятие перехват появилось даже ранее MTS (Microsoft Transaction Server). В приведенную выше схему полностью укладывается процесс создания нового экземпляра класса с заданной потоковой моделью в рамках СОМ. Вообще, Don Box называет принцип перехвата краеугольным камнем современного СОМ программирования.
В СОМ маршализация указателей на интерфейс требовалась при вызове через границу апартамента. В СОМ+ такая маршализация требуется при вызове через границу контекста. В соответствии с принципом перехвата только в рамках одного контекста можно использовать прямые указатели на интерфейс.
Как и в СОМ маршализация и демаршализация указателей на интерфейс выполняется автоматически при создании, активации объекта и при вызове функций, возвращающих указатели на интерфейс. В остальных случаях, для получения указателя на интерфейс объекта из другого контекста необходимо явным образом выполнить процедуры маршализации и демаршализации указателя на интерфейс. Дня этого можно использовать функции CoMarshalInterfасе и CoUnmarshalInterfасе. Для некоторой оптимизации этого процесса можно проектировать объекты с FTM и использовать GIT, как это было в СОМ.
Синхронизация
Ранее уже упоминалаось, что при программировании в СОМ+ рекомендуется выбирать для новых классов потоковыю модель ThreadingModei = Neutral. Все экземпляры такого класса будут размещаться в одном апартаменте NA. Основное преимущество этого апартамента состоит в том, что он не имеет связанных с ним потоков, и поток из любого другого апартамента, сделавший вызов метода объекта из NA, временно покидает свой апартамент и выполняет код вызванного метода. Отсутствие переключения потоков существенно снижает затраты на вызов. Однако, необходимо побеспокоиться о синхронизации. Сам апартамент NA никак не ограничивает возможность параллельного вызова одного и того же метода одного и того же объекта из NA.
В рамках СОМ синхронизация обеспечивалась либо написанием потоко-безопасного кода (например, путем использования критических секций), либо объект помещался в STA апартамент. В СОМ+ появляется новая возможность — декларация необходимости синхронизации путем задания нужного значения для соответствующего атрибута. Сама синхронизация обеспечивается через механизм, основанный на понятии активность.
Активность — множество из нескольких контекстов, которые могут находиться не только в различных апартаментах, но и в различных процессах и даже на различных машинах. Любой контекст входит не более чем в одну активность. Могут быть контексты, не входящие ни в одну активность.
Включение контекста в некоторую активность определяется атрибутом Synchronization входящих в контекст объектов. В таблице 3.1 приведены возможные значения этого атрибута и их влияние на вхождение контекста, которому будет принадлежать активируемый объект, в ту или иную активность.
При назначении значения атрибуту Synchronization необходимо учитывать некоторые ограничения. Именно, если потоковая модель класса ThreadIngModel=Apartment, или данный класс поддерживает активацию по необходимости, или он использует сервис транзакций, необходимо выбрать для значения атрибута синхронизации либо REQUIRED, либо REQUIRES_NEW.
Теперь рассмотрим собственно механизм синхронизации. На уровне процесса активность блокируется как только поступил вызов к одному из объектов одного из ее контекстов. Только после выполнения этого вызова блокировка снимается и другой вызов может войти в активность. Для предотвращения deadlock используется отслеживание цепочек вызовов.
Каждый вызов получает уникальный идентификатор (GUID), и все вызовы, сделанные для выполнения этого вызова, получают тот же идентификатор. Вызов, идентификатор которого совпадает с идентификатором вызова, блокировавшего активность, желающий войти в активность, входит в нее.
К сожалению, описанный механизм синхронизации не решает проблему синхронизации полностью. Блокировка при вызове объекта из некоторой активности устанавливается на уровне процесса. Это означает, что в случае, когда активность включает контексты из нескольких процессов, вызовы, направленные в контексты данной активности, но принадлежащие различным процессам, могут выполняться параллельно. Это может привести к deadlock. Пример приведен в упомянутой выше статье Don Box. Пусть поток X вызывает объект А, поток Y вызывает объект В, объекты А и В принадлежат одной активности, но разным процессам. В этом случае вызовы могут выполняться параллельно. Пусть теперь объект А вызвал объект В, а объект В вызвал объект А. Возникает deadlock, так как эти вызовы принадлежат разным цепочкам вызовов и блокируют друг друга.
Рецепт следующий. Не следует различным клиентам пользоваться одними и теми же объектами-серверами. Каждый клиент должен активировать для себя новый объект-сервер. Разделять следует только данные. Их согласованность будет обеспечиваться сервисом транзакций.
Рассмотрев понятие синхронизации можно поставить вопрос о роли апартаментов в СОМ+. Как говорит Don Box, их роль резко ограничена. Это привязка потоков к контекстам и только. Действительно, к каждому апартаменту кроме NA привязан один (в случае STA) или несколько (в случае МТА) потоков. Эти потоки могут вызвать любой метод любого объекта из соответствующего апартамента. Методы объекта из NA вообще могут быть вызваны из любого потока. Механизм синхронизации в СОМ+ определяет когда поток из апартамента может вызвать метод объекта, живущего в некотором контексте этого апартамента.
Распределенные транзакции
Основные понятия
Начнем с некоторой теории, точнее, с некоторого набора понятий, общих для различных моделей и стандартов, связанных с самим понятием распределенной транзакции.
Прежде всего надо разграничить понятия обычной (уровня одной базы данных) транзакции и распределенной транзакции. В первом случае имеется множество клиентов, одновременно обращающихся с запросами к одной базе данных. Во втором случае в логически единый процесс вовлечены несколько баз данных, управляемых независимыми СУБД. В случае сбоя необходимо выполнить откат не в одной, а во всех вовлеченных базах данных, даже в тех, с чьей точки зрения все операции по модификации данных были выполнены успешно.
В распределенную транзакцию вовлечены следующий объекты:
• Прикладные компоненты
Число и функции прикладных компонентов определяются бизнес-логикой приложения.
• Менеджеры ресурсов
Дня каждого ресурса, представляющего собой некоторую систему хранения данных со свойством восстановления после программных и технических сбоев, имеется свой менеджер ресурса.
• Менеджер транзакций
Обычно всеми транзакциями в рамках одной машины управляет один менеджер транзакций. В случае, когда транзакция распределена по нескольким машинам, она координируется при взаимодействии менеджеров транзакций со всех вовлеченных машин.
Транзакция — это некоторая единица работы, которую выполняют вышеописанные объекты в течении относительно короткого временного интервала (в СОМ+ по умолчанию транзакция длится не более 60 секунд). Транзакция должна обладать следующими ACID свойствами: