Proceso operativo DE COM+ CRM

  • Artículo

En funcionamiento normal, un componente de aplicación que se ejecuta en un proceso de aplicación de servidor usaría un CRM de COM+ mediante la creación de un trabajo de CRM. El trabajo de CRM implementa una interfaz COM específica de la tarea que está diseñada para realizar. El componente de aplicación debe ejecutarse en una transacción para que el trabajo de CRM herede la transacción del componente de aplicación. Los trabajadores de CRM siempre requieren una transacción.

Para acceder a COM+ CRM, el trabajador de CRM obtiene primero la interfaz ICrmLogControl , que permite al trabajador de CRM escribir registros en el registro duradero. El trabajador de CRM obtiene esta interfaz mediante la creación de un componente de distribuidor de CRM.

A continuación, el trabajador de CRM debe indicar al empleado de CRM el nombre del compensador de CRM que desea usar. Para ello, llama al método ICrmLogControl::RegisterCompensator . Después de llamar a este método, la infraestructura crm crea el compensador crm cuando se completa la transacción.

Una vez que el trabajador de CRM haya registrado su compensador de CRM, puede escribir registros en el registro de CRM mediante ICrmLogControl. El trabajador de CRM debe escribir por adelantado; es decir, debe escribir un registro en el registro que describe una acción antes de realizar realmente la acción, en caso de que se produzca un bloqueo inmediatamente después de completar la acción. Sin estas entradas de registro de escritura previa, no hay ninguna manera de corregir la acción.

Además, la escritura anticipada significa que el compensador de CRM, que es el componente que recibe las entradas de registro en la recuperación, debe tratar con el caso en el que se escribieron las entradas de registro, pero la acción no se produjo de hecho. Las acciones del compensador crm deben ser idempotentes; es decir, deben ser capaces de realizarse más de una vez, pero deben dar lugar al mismo resultado. Por ejemplo, establecer un saldo de cuenta en el valor de $100 es una acción idempotente; agregar $100 al saldo de la cuenta no es.

La interfaz ICrmLogControl proporciona los dos métodos siguientes para escribir registros de registro:

  • WriteLogRecordVariants se usa para escribir un registro estructurado que se crea como una colección de Variants. Se usa principalmente al desarrollar CRM en Microsoft Visual Basic.
  • WriteLogRecord se usa para escribir un registro no estructurado como BLOB de bytes. Se usa principalmente al desarrollar CRM en Microsoft Visual C++. Dado que las estructuras de registro de C suelen estar formadas por un conjunto de encabezados y campos que pueden estar dispersos en la memoria, el método WriteLogRecord implementa una funcionalidad de recopilación que reduce la copia de datos.

Nota:

No debe usar tipos de puntero de usuario dentro de estructuras de datos en un registro de registro. Los punteros ya no son válidos durante la fase de recuperación porque el compensador de CRM se ejecuta en un proceso diferente al del trabajador de CRM que escribió el registro. La inclusión de tipos de puntero en un registro de registro puede provocar que una aplicación se bloquee o se dañe durante la recuperación.

 

Ambos métodos de escritura escriben un registro en el disco, pero no garantizan la durabilidad del registro. Aunque permitir que las escrituras diferidas se acumulen antes de forzar al disco pueden mejorar el rendimiento, puede usar el método ICrmLogControl::ForceLog en su lugar para garantizar que todas las escrituras realizadas por CRM sean duraderas en el disco, lo que es importante para la recuperación de errores.

Cuando el trabajo de CRM se realiza con sus acciones y ha terminado de escribir y forzar los registros al registro, debe liberar ICrmLogControl. Cuando se completa la transacción (normalmente debido al componente de la aplicación que llama a SetComplete o SetAbort), la infraestructura de CRM crea el componente compensator de CRM, que implementa la interfaz ICrmCompensator o la interfaz ICrmCompensatorVariants . Estas interfaces se usan para pasar los registros no estructurados (Visual C++) o estructurados (Visual Basic) al compensador de CRM junto con las notificaciones de resultados de la transacción.

El compensador crm recibe primero una notificación de la fase de preparación de la finalización de la transacción y puede votar sí o no a la solicitud de preparación. Si el compensador crm vota no, no recibe ninguna notificación de anulación adicional. Si vota sí a la solicitud de preparación, recibe las notificaciones de confirmación o anulación. En el caso de una anulación de cliente, no se reciben notificaciones de preparación, solo se anulan las notificaciones. El compensador de CRM debe estar preparado para controlar todos estos casos y también debe controlar el caso en el que el trabajador de CRM no haya escrito correctamente registros. El compensador de CRM no debe suponer que la misma instancia de CRM Compensator recibirá las notificaciones de fase 1 (preparación) y de la fase 2 (confirmación o anulación), ya que podrían interrumpirse por la recuperación.

Normalmente, un compensador de CRM usa la notificación de anulación para invertir la acción realizada por el trabajador de CRM. El trabajador de CRM puede dejar algún estado disponible en caso de que necesite revertir su acción. Ese estado puede estar totalmente contenido en los registros de registro y, si no es así, el compensador de CRM debe limpiar ese estado si la transacción se confirma. Esta es la razón por la que el compensador crm recibe la notificación de confirmación. El compensador crm no se ejecuta en una transacción DTC.

El compensador crm puede registrar nuevos registros si es necesario mediante ICrmLogControl, que recibe a medida que se crea. Tanto el trabajador de CRM como el compensador de CRM también pueden olvidar el último registro que escribieron, lo que podría ser necesario para evitar la recuperación innecesaria.

Conceptos de Resource Manager de compensación de COM+

Inicio y recuperación de CRM de COM+