Escenarios que usan transacciones atómicas
En los escenarios siguientes se describe el uso de transacciones atómicas.
Escenario 1: Transacción atómica con COM+ ServicedComponent
La orquestación siguiente muestra cómo usar RetryTransactionException con transacciones atómicas. Aunque los controladores de excepción se pueden incluir directamente para un ámbito atómico, el ámbito puede incluir un ámbito no transaccional que puede tener un controlador de excepción. ServicedComponent se inscribe en la misma transacción DTC y se detecta cualquier excepción generada por el componente y se vuelve a iniciar como RetryTransactionException. (Se supone que la propiedad Retry se establece en True para el ámbito atómico).
Tenga en cuenta que la orquestación se habría suspendido y que la acción de la forma MessageAssignment se habría revertido incluso si no se produce la excepción RetryTransactionException . No obstante, este patrón permite aportar estabilidad a la aplicación donde se producen reintentos automáticamente.
Transacción atómica con COM+ ServicedComponent
Escenario 2: Uso de adaptadores de transacción con transacciones atómicas
La siguiente orquestación muestra cómo usar transacciones atómicas con el adaptador de SQL. Toda la orquestación se marca como de larga duración con transacciones atómicas individuales para las dos partes lógicas de trabajo: Insertar un nuevo cliente e Insertar detalles del pedido para el cliente.
Si, por cualquier motivo, se produce un error en la inserción del pedido, debería deshacer la inserción del cliente. En el ejemplo se usa el adaptador de SQL para hacer el trabajo de base de datos. Tal y como se mencionó anteriormente, el ámbito asociado con una transacción atómica se completa cuando se envía el mensaje a la base de datos de cuadro de mensajes. Esto implica que, una vez que el motor ha enviado correctamente el mensaje en los ámbitos Scope_InsertCustomer y Scope_InsertOrder, se confirma cada uno de los ámbitos. El adaptador de SQL crea una nueva transacción para la inserción real del cliente o el pedido.
Los puertos tienen una propiedad “Notificación de entrega” para validar que el mensaje se ha enviado correctamente a través del puerto de envío. Si la propiedad Notificación de entrega está establecida en “Transmitted”, se coloca una suscripción de recepción antes del punto de confirmación transaccional de la operación de envío. No obstante, en el caso de ámbitos atómicos, la suscripción de recepción se coloca en el ámbito primario envolvente.
En el escenario donde la transacción SQL InsertOrder produce un error, se devolverá un mensaje de confirmación negativa y se confirma “Scope_InsertOrder”. Una vez que el puerto de envío agota los reintentos configurados, se genera una excepción DeliveryFailureException. El controlador de excepción predeterminado detectará esta excepción, que ejecutará el proceso de compensación predeterminado. Esto invocará a los controladores de compensación asociados a Scope_InsertCustomer y Scope_InsertOrder, lo que provocará la operación deshacer para la inserción de la información de cliente.
Nota
La anidación de los dos ámbitos en un ámbito de larga ejecución y la invocación de la forma Compensar (dirigida a la transacción de larga ejecución) desde el controlador de excepción para el ámbito de larga ejecución producirá el mismo comportamiento descrito más arriba. La orquestación completa no se podría marcar como atómica puesto que las transacciones atómicas no permiten transacciones anidadas.
Adaptadores de transacción con transacciones atómicas
