назначении значения атрибуту Synchronization необходимо учитывать некоторые ограничения. Именно, если потоковая модель класса ThreadIngModel=Apartment, или данный класс поддерживает активацию по необходимости, или он использует сервис транзакций, необходимо выбрать для значения атрибута синхронизации либо REQUIRED, либо REQUIRES_NEW.

Теперь рассмотрим собственно механизм синхронизации. На уровне процесса активность блокируется как только поступил вызов к одному из объектов одного из ее контекстов. Только после выполнения этого вызова блокировка снимается и другой вызов может войти в активность. Для предотвращения deadlock используется отслеживание цепочек вызовов.

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

К сожалению, описанный механизм синхронизации не решает проблему синхронизации полностью. Блокировка при вызове объекта из некоторой активности устанавливается на уровне процесса. Это означает, что в случае, когда активность включает контексты из нескольких процессов, вызовы, направленные в контексты данной активности, но принадлежащие различным процессам, могут выполняться параллельно. Это может привести к deadlock. Пример приведен в упомянутой выше статье Don Box. Пусть поток X вызывает объект А, поток Y вызывает объект В, объекты А и В принадлежат одной активности, но разным процессам. В этом случае вызовы могут выполняться параллельно. Пусть теперь объект А вызвал объект В, а объект В вызвал объект А. Возникает deadlock, так как эти вызовы принадлежат разным цепочкам вызовов и блокируют друг друга.

Рецепт следующий. Не следует различным клиентам пользоваться одними и теми же объектами-серверами. Каждый клиент должен активировать для себя новый объект-сервер. Разделять следует только данные. Их согласованность будет обеспечиваться сервисом транзакций.

Рассмотрев понятие синхронизации можно поставить вопрос о роли апартаментов в СОМ+. Как говорит Don Box, их роль резко ограничена. Это привязка потоков к контекстам и только. Действительно, к каждому апартаменту кроме NA привязан один (в случае STA) или несколько (в случае МТА) потоков. Эти потоки могут вызвать любой метод любого объекта из соответствующего апартамента. Методы объекта из NA вообще могут быть вызваны из любого потока. Механизм синхронизации в СОМ+ определяет когда поток из апартамента может вызвать метод объекта, живущего в некотором контексте этого апартамента.

Распределенные транзакции

Основные понятия

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

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

В распределенную транзакцию вовлечены следующий объекты:

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

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

• Менеджеры ресурсов

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

• Менеджер транзакций

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

Транзакция — это некоторая единица работы, которую выполняют вышеописанные объекты в течении относительно короткого временного интервала (в СОМ+ по умолчанию транзакция длится не более 60 секунд). Транзакция должна обладать следующими ACID свойствами:

• Atomicity — атомарность транзакции

Атормарность означает необходимость реализации принципа "все или ничего". Иными словами, либо транзакция завершается к удовольствию всех ее участников, либо выполняется полный откат назад, к положению до начала транзакции.

• Consistency — целостность распределенных данных

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

• Isolation — изоляция транзакции

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

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

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

• Durability — сохранность результатов транзакции

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

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

• Демаркация транзакции

Данное понятие означает способ определения единицы работы, составляющей одну атомарную транзакцию. Работа состоит из некоторой совокупности операций (транзакционных операций), выполняемых вовлеченными в транзакцию объектами. Имеется два способа демаркации транзакции:

♦ Программная демаркация

Этот способ обычно применяется при следовании процедурной парадигме программирования. Некоторому потоку приписывается метка транзакции, и все операции, выполняемые в этом потоке до момента выполнения команды успешного завершения или прерывания транзакции, принадлежат данной транзакции. Транзакцию можно временно приостанавливать, снимая метку с потока и вновь помечивая поток.

♦ Декларативная демаркация

Данный способ применяется в рамках технологий компонентного программирования. Требования каждого прикладного компонента к среде выполнения описываются набором атрибутов, которые просматриваются системой в момент активации компонента. Если активируемый компонент требует своего выполнения в рамках транзакции, все выполняемые им операции будут выполняться в рамках некоторой транзакции. Какой именно транзакции — определяется как требованиями активируемого компонента, так и требованиями компонента, инициировавшего активацию (активатора). Активируемый компонент может выполняться в рамках транзакции, в которой выполняется активатор (конечно, если такая транзакция имеется), или во вновь созданной транзакции, или выполняться вне какой-либо транзакции.

• Контекст транзакции

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

• Регистрация ресурсов

Каждый вовлекаемый в транзакцию менеджер ресурсов регистрируется у менеджера транзакций. Эта регистрация снимается по завершении транзакции.

• Двух-фазный протокол завершения транзакции

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