Transacciones atómicas

Las orquestaciones de BizTalk pueden diseñarse para ejecutar elementos discretos de trabajo, siguiendo el clásico concepto "ACID" de una transacción. Estas unidades discretas o atómicas de trabajo, cuando se ejecutan, llevan el proceso empresarial de un estado coherente a un estado nuevo, coherente y duradero que se aísla de otras unidades de trabajo. Normalmente, esto se realiza mediante la construcción Scope que encapsula las unidades de trabajo con la semántica transaccional. También se puede definir la orquestación completa como una transacción atómica sin el uso de ámbitos. No obstante, los ámbitos no pueden marcarse como transaccionales a menos que la propia orquestación se marque como transacción atómica o de larga duración. Las transacciones atómicas garantizan que todas las actualizaciones parciales se revertirán automáticamente si se produce un error durante la actualización de la transacción, y los efectos de la transacción se borrarán (excepto los efectos de cualquier llamada .NET que se haga en la transacción). Las transacciones atómicas en orquestaciones de BizTalk se parecen a las transacciones del coordinador de transacciones distribuidas (DTC) en que suelen ser de corta duración y tener los cuatro atributos "ACID" (atomicidad, coherencia, aislamiento y durabilidad):

• Atomicidad

  Una transacción representa una unidad atómica de trabajo. En una transacción se realizan todas las modificaciones o ninguna de ellas.

• Coherencia

  Cuando se confirma, una transacción debe preservar 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 coherente internamente antes de que se iniciase la transacción, debe seguir siéndolo una vez confirmada ésta. El programador de la aplicación es el principal responsable de garantizar esta propiedad.

• 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, del mismo modo que si se tratara de transacciones ejecutadas en serie.

• Durabilidad

  Una vez confirmada una transacción, todas las modificaciones permanecen en el sistema de forma predeterminada. Las modificaciones persisten aunque se produzca un error del sistema.

  Las transacciones atómicas utilizadas en orquestaciones de BizTalk admiten los siguientes niveles de aislamiento:

• Read Committed

  Los bloqueos compartidos se mantienen mientras se están leyendo los datos para evitar lecturas erróneas. Sin embargo, es posible cambiar los datos antes del fin de la transacción, lo que provoca lecturas no repetibles o datos fantasma.

• Repeatable Read

  Los bloqueos se realizan sobre todos los datos usados en una consulta para evitar que otros usuarios actualicen dichos datos. De este modo, se evitan lecturas no repetibles, pero todavía pueden aparecer filas ficticias.

• Serializable

  Se coloca un bloqueo de intervalo que impide que otros usuarios actualicen o inserten filas en la base de datos hasta que no 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 se aíslan 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 se deben aislar de otras transacciones), debe usar transacciones atómicas exclusivamente.

Cuando se producen errores en una transacción atómica, todos los estados se restablecen como si la instancia de orquestación nunca hubiese entrado en el ámbito. La regla que BizTalk aplica a transacciones atómicas es que todas las variables (no solo las locales para el ámbito) participen en la transacción. Todas las variables y mensajes no serializables utilizados en una transacción atómica deben declararse como locales para el ámbito; en caso contrario, el compilador mostrará el error que indica que la variable en cuestión no está marcada como serializable. Se presupone que todos los ámbitos atómicos están "sincronizados" y el compilador de orquestaciones mostrará una advertencia sobre uso redundante si, en efecto, se utiliza la palabra clave "synchronized" para ámbitos atómicos. La sincronización de los datos compartidos va desde el inicio del ámbito hasta la correcta finalización de éste (incluida la persistencia de estado al final del ámbito), o bien hasta la finalización del controlador de excepción (en caso de que se produzcan errores). El dominio de sincronización no se extiende al controlador de compensación.

Las transacciones atómicas pueden asociarse a valores de tiempo de espera, momento a partir del cual la orquestación detendrá la transacción y la instancia se suspenderá. Si una transacción atómica contiene una forma Recepción, una forma Envío o una forma Iniciar orquestación, las acciones correspondientes no se llevarán a cabo hasta que no se haya confirmado la transacción.

Una transacción atómica reintenta cuando el usuario inicia deliberadamente una excepción RetryTransactionException o si se genera una persistenceException en el momento en que la transacción atómica intenta confirmarse. Esto último ocurriría si, por ejemplo, la transacción atómica formase parte de una transacción DTC distribuida y algún otro participante en dicha transacción la detuviese. 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 intervalo predeterminado entre cada reintento es de dos segundos (pero se puede modificar). Una vez concluidos los 21 reintentos, si sigue sin poder confirmarse la transacción, se suspenderá la instancia de toda la orquestación. Se puede reanudar manualmente y volverá a comenzar, con un contador nuevo, desde el principio del ámbito atómico infractor.

Nota

Solo RetryTransactionException y PersistenceException pueden hacer que un ámbito atómico vuelva a intentarlo. Cualquier otra excepción que se produzca en un ámbito atómico no puede provocar 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 para anidar otras transacciones que no pueden anidar otras transacciones o incluir bloques Catch - Exception .

Transacciones DTC

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

Nota

Una transacción atómica no puede contener cualquier otra transacción ni controladores de excepción.

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 utilizar un objeto no serializable dentro de una orquestación, debe utilizarlo únicamente dentro de una transacción atómica. Cualquier uso de un objeto de este tipo fuera de una transacción atómica supone un riesgo en lo que a pérdida de datos se refiere cuando el motor guarda la orquestación.

Precaución

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

Consulte también

Escenarios de uso de transacciones atómicas
Transacciones de ejecución prolongada