Transacciones de Long-Running

Las transacciones de larga duración son construcciones habitualmente utilizadas e importantes en las orquestaciones de BizTalk. Proporcionan facilidades para la compensación basada en ámbitos personalizados, el manejo de excepciones en ámbitos personalizados y la capacidad de anidar transacciones, lo cual ofrece una gran flexibilidad al diseñar una arquitectura de transacciones robusta.

Se usa una transacción de larga duración cuando es posible que la transacción tenga que ejecutarse durante un período prolongado y no necesite propiedades ACID completas (es decir, no es necesario garantizar el aislamiento de los datos de otras transacciones). Una transacción de larga duración puede tener largos períodos de inactividad, a menudo debido a la espera de que lleguen mensajes externos.

Las transacciones de larga duración poseen coherencia y durabilidad, pero no atomicidad y aislamiento. Los datos dentro de una transacción de larga duración no están bloqueados; otros procesos o aplicaciones pueden modificarlo. La propiedad de aislamiento para las actualizaciones de estado no se mantiene porque no es práctico mantener bloqueos durante mucho tiempo.

El compromiso de una transacción de larga duración es diferente del compromiso de una transacción atómica. No hay ninguna suposición implícita de coordinación distribuida con respecto al resultado (una transacción de larga duración solo existe dentro de una sola instancia de orquestación). En su lugar, se considera que se confirma una transacción de larga duración cuando se ha completado la última instrucción en ella. No hay ninguna reversión "automática" del estado en caso de anulación de transacción. Puede lograr esto mediante programación a través de los controladores de excepción y compensación.

Un ámbito puede definir su propio estado declarando variables, mensajes y componentes de .NET. Una transacción de larga duración tiene acceso a la información de estado de su propio ámbito, cualquier ámbito que lo incluya y cualquier información de estado definida globalmente dentro de la orquestación. No tiene acceso a la información de estado de ningún ámbito que no lo incluya.

Anidamiento

Las transacciones de larga duración pueden contener transacciones atómicas u otras transacciones de larga duración. Se pueden anidar en profundidades arbitrarias. Por ejemplo, la transacción puede contener otras dos transacciones de larga duración, cada una de las cuales podría contener transacciones atómicas.

El anidamiento es especialmente útil cuando uno o varios componentes de la transacción general deben ser atómicos, mientras que la transacción general debe ser de larga duración. Considere el ejemplo de recepción y cumplimiento de un pedido de compra. El pedido de compra puede llegar en cualquier momento y los distintos pasos para completar el pedido pueden tardar tiempo en producirse, pero aún desea tratar todo el proceso como una transacción. La transacción general en este caso debe ser claramente de larga duración, pero un paso individual, como la confirmación de un pago, puede que tenga que ser atómico.

Nota:

No se puede anidar un ámbito transaccional dentro de un ámbito o orquestación que no sea transaccional. Un ámbito o orquestación envolvente que no sea transaccional no administrará el estado, ya que debe controlar correctamente la administración de estado de cualquier ámbito dentro de él.

Nota:

Una transacción sincronizada no puede incluir otras transacciones ni ámbitos sincronizados.

Compensación

Una transacción de larga duración puede especificar un bloque de compensación al que se llamará para compensar las actividades de la transacción, después de confirmarla. Es posible que simplemente deshaga la transacción cuando sea factible o realice alguna otra función, como la notificación, que ayuda a mitigar los efectos de la transacción de alguna manera. Si no agrega su propio código de compensación, el motor en tiempo de ejecución llamará de forma predeterminada a los bloques de compensación de las transacciones internas, tanto de larga duración como atómicas, en orden inverso, empezando por la última transacción confirmada y terminando con la primera transacción confirmada.

Nota:

La compensación solo se puede realizar en una transacción que se haya completado correctamente.

Tolerancia a errores

Las transacciones admiten la tolerancia a errores para la recuperación de errores internos (como errores de equipo y errores de software) y errores externos (como los mensajes de cancelación). Las actualizaciones parciales dentro de transacciones de larga duración no se revierten automáticamente cuando se produce un error de transacción, en contraste con las transacciones ACID, donde sí se revierten automáticamente.

Cuando se produce un error, se llama al bloque de código de excepción para la transacción de larga duración. El bloque de código de excepción contiene un conjunto de controladores de errores que se escriben para tratar cualquiera de los errores que pueden surgir durante la ejecución de la transacción. Puede confiar en el último estado conocido de los mensajes, variables y objetos en el control del error.

Normalmente, querrá que el manejador de excepciones evalúe el estado de la orquestación en el momento en que ocurre la excepción, realice cualquier acción necesaria en función de ese estado y llame a las compensaciones de las transacciones encadenadas.

La ejecución de la transacción prolongada se interrumpe cuando se produce un error. No se puede reanudar después de que se produzca un error.

Véase también

Escenarios con transacciones Long-Running
Transacciones atómicas
Uso de transacciones y control de excepciones