Поделиться через

Рабочий процесс COM+ CRM

В обычном режиме работы компонент приложения, работающий в процессе серверного приложения, будет использовать COM+ CRM, создавая CRM-воркер. Работник CRM реализует COM-интерфейс, характерный для задачи, предназначенной для выполнения. Компонент приложения должен выполняться в рамках транзакции, чтобы агент CRM наследовал транзакцию компонента приложения. Для работников CRM всегда требуется транзакция.

Чтобы получить доступ к COM+ CRM, работник CRM сначала получает интерфейс ICrmLogControl, который позволяет писать данные в устойчивый журнал. Сотрудник CRM получает этот интерфейс через создание компонента диспетчера CRM.

Далее сотрудник CRM должен сообщить работнику CRM имя компенсатора CRM, который он хочет использовать. Это делается путем вызова метода ICrmLogControl::RegisterCompensator. После вызова этого метода компенсатор CRM создается инфраструктурой CRM после завершения транзакции.

После регистрации компенсатора CRM сотрудник может вносить записи в журнал CRM с помощью ICrmLogControl. Работник CRM должен предварительно записать; то есть он должен сделать запись в журнале, описывающую действие, прежде чем фактически выполнить его, на случай сбоя, который может произойти сразу после выполнения действия. Без этих записей журнала предзаписи нет способа компенсировать действие.

Кроме того, предварительная запись означает, что компенсатор CRM, являющийся компонентом для получения журнальных записей при восстановлении, должен рассчитывать на ситуацию, когда журнальные записи были записаны, но действие на самом деле не произошло. Действия компенсатора CRM должны быть идемпотентными; то есть они должны быть способны выполняться более одного раза, но должны привести к одному и тому же результату. Например, установление баланса учетной записи на сумму $100 является идемпотентным действием; добавление $100 на баланс учетной записи не является.

ИнтерфейсICrmLogControlпредоставляет следующие два метода записи журнала:

  • WriteLogRecordVariants используется для написания структурированной записи журнала, созданной в виде коллекции Variants. Он в первую очередь используется при разработке CRM в Microsoft Visual Basic.
  • WriteLogRecord используется для записи неструктурированной записи журнала в виде BLOB байтов. Он используется в основном при разработке CRM в Microsoft Visual C++. Поскольку структуры записей в C часто состоят из набора заголовков и полей, которые могут быть разбросаны в памяти, метод WriteLogRecord реализует возможность сбора, которая снижает копирование данных.

Заметка

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

 

Оба этих метода записи фиксируют запись журнала на диск, но не гарантируют её надёжность. Позволяя отложенным записям накапливаться, прежде чем принудительно записывать их на диск, можно повысить производительность, однако можно использовать метод ICrmLogControl::ForceLog, чтобы гарантировать, что все операции записи, осуществленные CRM, сохраняются на диске, что важно для восстановления после сбоев.

Когда работник CRM выполняет свои действия и завершает запись и принудительно записывает записи в журнал, он должен освободить ICrmLogControl. Когда транзакция завершается (обычно из-за компонента приложения, вызывающего SetComplete или SetAbort), инфраструктура CRM создает компонент компенсатора CRM, который реализует интерфейс ICrmCompensator или интерфейс ICrmCompensatorVariants. Эти интерфейсы используются для передачи неструктурированных (Visual C++) или структурированных записей (Visual Basic) в компенсатор CRM вместе с уведомлениями о результатах транзакций.

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

Как правило, компенсатор CRM использует уведомление об прерывании для отмены действия, выполняемого рабочей ролью CRM. Сотрудник CRM может оставить некоторые данные доступными на случай, если потребуется отменить свое действие. Состояние может полностью содержаться в записях журнала, а если нет, компенсатор CRM должен очистить это состояние, если транзакция подтверждается. Именно поэтому компенсатор CRM получает уведомление о подтверждении фиксации. Компенсатор CRM не выполняется в рамках транзакции DTC.

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

Компенсирующий ресурсный менеджер в COM+: Основные понятия

Запуск и восстановление COM+ CRM