Processo Operacional CRM COM+

  • Artigo

Em operação normal, um componente de aplicativo em execução em um processo de aplicativo de servidor usaria um CRM COM+ criando um trabalhador do CRM. O trabalhador do CRM implementa uma interface COM específica para a tarefa que foi projetada para executar. O componente de aplicativo deve estar em execução em uma transação para que o trabalhador do CRM herde a transação do componente de aplicativo. Os trabalhadores do CRM sempre exigem uma transação.

Para acessar o CRM COM+, o trabalhador do CRM primeiro obtém a interface ICrmLogControl , que permite que o trabalhador do CRM grave registros no log durável. O trabalhador do CRM obtém essa interface criando um componente de atendente do CRM.

Em seguida, o trabalhador do CRM deve informar ao atendente do CRM o nome do Compensador de CRM que deseja usar. Ele faz isso chamando o método ICrmLogControl::RegisterCompensator. Depois que esse método é chamado, o CRM Compensator é criado pela infraestrutura do CRM quando a transação é concluída.

Depois que o trabalhador do CRM registrar seu CRM Compensator, ele poderá gravar registros no log do CRM usando ICrmLogControl. O trabalhador do CRM deve escrever antecipadamente, ou seja, deve gravar um registro no log descrevendo uma ação antes de realmente executar a ação, caso ocorra uma falha imediatamente após a conclusão da ação. Sem esses registros de log write-ahead, não há como corrigir a ação.

Além disso, gravar com antecedência significa que o CRM Compensator, que é o componente que recebe os registros de log na recuperação, deve lidar com o caso em que os registros de log foram gravados, mas a ação de fato não ocorreu. As ações do Compensador de CRM devem ser idempotentes, ou seja, devem ser capazes de ser realizadas mais de uma vez, mas devem levar ao mesmo resultado. Por exemplo, definir um saldo de conta para o valor de R$ 100 é uma ação idempotente; adicionar $100 ao saldo da conta não é.

A interface ICrmLogControl fornece os dois métodos a seguir para gravar registros de log:

  • WriteLogRecordVariants é usado para gravar um registro de log estruturado que é criado como uma coleção de variantes. Ele é usado principalmente ao desenvolver CRMs no Microsoft Visual Basic.
  • WriteLogRecord é usado para gravar um registro de log não estruturado como BLOBs de bytes. Ele é usado principalmente ao desenvolver CRMs no Microsoft Visual C++. Como as estruturas de registro em C geralmente são compostas por um conjunto de cabeçalhos e campos que podem estar espalhados na memória, o método WriteLogRecord implementa um recurso de coleta que reduz a cópia de dados.

Observação

Você não deve usar tipos de ponteiro dentro de estruturas de dados em um registro de log. Os ponteiros não são mais válidos durante a fase de recuperação porque o CRM Compensator é executado em um processo diferente daquele do trabalhador do CRM que escreveu o registro de log. A inclusão de tipos de ponteiro em um registro de log pode fazer com que um aplicativo trave ou se corrompa durante a recuperação.

 

Ambos os métodos de gravação gravam um registro de log no disco, mas não garantem a durabilidade do registro. Embora permitir que gravações lentas se acumulem antes de forçar o disco possa melhorar o desempenho, você pode usar o método ICrmLogControl::ForceLog para garantir que todas as gravações feitas pelo CRM sejam duráveis no disco, o que é importante para a recuperação de falhas.

Quando o trabalhador do CRM terminar suas ações e tiver terminado de gravar e forçar registros no log, ele deverá liberar ICrmLogControl. Quando a transação é concluída (normalmente devido ao componente de aplicativo chamando SetComplete ou SetAbort), a infraestrutura do CRM cria o componente CRM Compensator, que implementa a interface ICrmCompensator ou a interface ICrmCompensatorVariants. Essas interfaces são usadas para passar os registros não estruturados (Visual C++) ou estruturados (Visual Basic) para o CRM Compensator junto com as notificações de resultado da transação.

O CRM Compensator é primeiro notificado da fase de preparação da conclusão da transação e pode votar sim ou não para a solicitação de preparação. Se o CRM Compensator votar não, ele não receberá mais notificações de anulação. Se ele votar sim para a solicitação de preparação, ele receberá as notificações de confirmação ou anulação. No caso de um cliente abortar, nenhuma notificação de preparação é recebida, apenas notificações de anulação. O CRM Compensator deve estar preparado para lidar com todos esses casos e também deve lidar com o caso em que nenhum registro de log foi gravado com êxito pelo trabalhador do CRM. O CRM Compensator não deve assumir que a mesma instância do CRM Compensator receberá as notificações da fase 1 (preparar) e da fase 2 (confirmar ou anular), pois elas podem ser interrompidas pela recuperação.

Normalmente, um CRM Compensator usa a notificação de interrupção para reverter a ação executada pelo trabalhador do CRM. O trabalhador do CRM pode deixar algum estado disponível caso precise reverter sua ação. Esse estado pode estar totalmente contido nos registros de log e, caso contrário, o CRM Compensator precisará limpar esse estado se a transação for confirmada. Esta é a razão pela qual o CRM Compensator recebe a notificação de confirmação. O CRM Compensator não é executado em uma transação DTC.

O CRM Compensator pode registrar novos registros, se necessário, usando ICrmLogControl, que ele recebe à medida que é criado. Tanto o trabalhador do CRM quanto o CRM Compensator também podem esquecer o último registro de log que escreveram, o que pode ser necessário para evitar a recuperação desnecessária.

Conceitos do COM+ Compensating Resource Manager

Inicialização e recuperação do CRM COM+