Transacciones atómicas

Las orquestaciones de BizTalk se pueden diseñar para ejecutar partes discretas del trabajo, siguiendo el concepto clásico "ACID" de una transacción. Estas unidades de trabajo discretas o atómicas, cuando se realizan, mueven el proceso de negocio de un estado coherente a un estado nuevo, coherente y duradero que está aislado de otras unidades de trabajo. Normalmente, esto se hace mediante la construcción Scope que encapsula las unidades de trabajo con la semántica transaccional. Toda la orquestación también se puede definir como una transacción atómica sin el uso de ámbitos. Sin embargo, los ámbitos no se pueden marcar como transaccionales a menos que la propia orquestación esté marcada como un tipo de transacción atómico o de larga duración. Las transacciones atómicas garantizan que las actualizaciones parciales se revierten automáticamente en caso de error durante la actualización transaccional y que se borran los efectos de la transacción (excepto los efectos de las llamadas de .NET realizadas en la transacción). Las transacciones atómicas en orquestaciones de BizTalk son similares a las transacciones del coordinador de transacciones distribuidas (DTC) en que suelen ser de corta duración y tienen los cuatro atributos "ACID" (atomicidad, coherencia, aislamiento y durabilidad):

• Atomicity

  Una transacción representa una unidad atómica de trabajo. Ya sea que se realicen todas las modificaciones dentro de una transacción o no se realice ninguna modificación.

• Coherencia

  Cuando se confirma, una transacción debe conservar la integridad de los datos dentro del sistema. Si una transacción realiza una modificación de datos en una base de datos que era internamente coherente antes de iniciar la transacción, la base de datos todavía debe ser coherente internamente cuando se confirma la transacción. Garantizar que esta propiedad es principalmente responsabilidad del desarrollador de aplicaciones.

• Aislamiento

  Las modificaciones realizadas por transacciones simultáneas deben aislarse de las modificaciones realizadas por otras transacciones simultáneas. Las transacciones aisladas que se ejecutan simultáneamente realizan modificaciones que conservan la coherencia interna de la base de datos exactamente como lo harían si las transacciones se ejecutaran en serie.

• Durability

  Una vez confirmada una transacción, todas las modificaciones se colocan permanentemente en el sistema de forma predeterminada. Las modificaciones se conservan incluso si se produce un error del sistema.

  Los siguientes niveles de aislamiento son compatibles con las transacciones atómicas usadas en orquestaciones de BizTalk:

• Lectura confirmada

  Los bloqueos compartidos se mantienen mientras se leen los datos para evitar lecturas sucias, pero los datos se pueden cambiar antes del final de la transacción, lo que da lugar a lecturas no repetibles o datos fantasma.

• Lectura repetible

  Los bloqueos se colocan en todos los datos que se usan en una consulta, lo que impide que otros usuarios actualicen los datos. Esto evita las lecturas no repetibles, pero las filas fantasma siguen siendo posibles.

• Serializable

  Se coloca un bloqueo de intervalo que impide que otros usuarios actualicen o inserten filas en la base de datos hasta que se complete la transacción.

  BizTalk Server garantiza que los cambios de estado dentro de una transacción atómica (como las modificaciones en variables, mensajes y objetos) estén visibles fuera del ámbito de la transacción atómica solo tras el compromiso de la transacción. Los cambios de estado intermedios están aislados de otras partes de una orquestación.

Nota:

Si una transacción atómica contiene una forma Receive , una forma Send o una forma Start Orchestration , las acciones correspondientes no se realizarán hasta que la transacción se haya confirmado.

Si necesita propiedades ACID completas en los datos (por ejemplo, cuando los datos deben aislarse de otras transacciones), debe usar transacciones atómicas exclusivamente.

Cuando se produce un error en una transacción atómica, todos los estados se restablecen como si la instancia de orquestación nunca entrara en el ámbito. La regla que BizTalk tiene para las transacciones atómicas es que todas las variables (no solo locales al ámbito) participan en la transacción. Todas las variables y los mensajes no serializables utilizados en una transacción atómica deben declararse dentro del ámbito local; de lo contrario, el compilador proporcionará el error "la variable... no está marcada como serializable". Se supone que todos los ámbitos atómicos están "sincronizados" y el compilador de orquestación proporcionará una advertencia para el uso redundante, si realmente se usa la palabra clave sincronizada para ámbitos atómicos. La sincronización de los datos compartidos se extiende desde el principio del ámbito hasta la finalización correcta del ámbito (incluida la persistencia de estado al final del ámbito) o hasta la finalización del controlador de excepciones (en caso de errores). El dominio de sincronización no se extiende al controlador de compensación.

Las transacciones atómicas se pueden asociar a valores de tiempo de espera en los que la orquestación detendrá la transacción y se suspenderá la instancia. Si una transacción atómica contiene un elemento de recepción, un elemento de envío o un elemento de inicio de orquestación, las acciones correspondientes no se llevarán a cabo hasta que la transacción se haya confirmado.

Una transacción atómica se vuelve a intentar cuando el usuario lanza deliberadamente una RetryTransactionException o si se genera una PersistenceException en el momento en que la transacción atómica intenta confirmarse. Esto último podría ocurrir si, por ejemplo, la transacción atómica formaba parte de una transacción DTC distribuida y algún otro participante de esa transacción detuvo la transacción. Del mismo modo, si hubiera problemas de conectividad de base de datos en el momento en que la transacción intentaba confirmarse, también habría una excepción PersistenceException generada. Si esto sucede para un ámbito atómico que tiene Retry=True, volverá a intentarlo hasta 21 veces. El retraso entre cada reintento es de dos segundos de forma predeterminada (pero es modificable). Una vez agotados los 21 reintentos, si la transacción sigue sin poder confirmarse, se suspende toda la instancia de orquestación. Se puede reanudar manualmente y comenzará de nuevo, con un contador reiniciado, desde el principio del ámbito atómico en cuestión.

Nota:

Solo RetryTransactionException y PersistenceException pueden hacer que el ámbito atómico vuelva a intentarlo. Cualquier otra excepción generada en un ámbito atómico no puede hacer que vuelva a intentarlo, incluso si la propiedad Retry está establecida en True. El retraso predeterminado de dos segundos entre cada dos reintentos consecutivos se puede invalidar mediante una propiedad pública en RetryTransactionException (si es la excepción que se usa para provocar los reintentos).

Los ámbitos atómicos tienen restricciones que impiden el anidamiento de otras transacciones o la inclusión de bloques Catch - Exception.

Transacciones DTC

Aunque las transacciones atómicas se comportan como transacciones DTC, no son transacciones DTC explícitamente de forma predeterminada. Puede convertirlos explícitamente en transacciones DTC, siempre que los objetos que se usen en la transacción sean objetos COM+ derivados de System.EnterpriseServices.ServicedComponents y que los niveles de aislamiento coinciden entre los componentes de transacción.

Nota:

Una transacción atómica no puede contener ninguna otra transacción dentro de ella, ni puede contener controladores de excepciones.

Nota:

Una transacción atómica no puede contener acciones de envío y recepción coincidentes, es decir, un par de solicitud-respuesta o un envío y recepción que usan el mismo conjunto de correlación.

Objetos no serializables

Si desea usar un objeto no serializable dentro de una orquestación, solo debe usarlo dentro de una transacción atómica. Cualquier uso de este tipo de objeto fuera de una transacción atómica corre el riesgo de pérdida de datos cada vez que el motor conserva la orquestación.

Precaución

Cada ámbito Atomic representa un punto de persistencia y lo que significa es que el estado de la orquestación se guarda en la base de datos en cada punto de persistencia. El uso extenso del ámbito Atómico aumentará la latencia en la orquestación. En lugar de usar el ámbito atómico para crear objetos no serializables, puede usar llamadas a métodos estáticos que no requieren ámbitos atómicos, lo que elimina la necesidad de los puntos de persistencia.

Véase también

Escenarios con transacciones atómicas
Transacciones de larga duración