Mensajería transaccional

La base del modelo de programación de Service Broker es la mensajería transaccional. Cualquier operación que implique Service Broker forma parte de la transacción actual. Service Broker no confirma una operación de mensajería hasta que se confirme la transacción actual. Si la transacción se revierte, Motor de base de datos garantiza que todas las operaciones de mensajería que forman parte de esta operación también se revierten. Una aplicación administra las operaciones de mensajería como parte de la administración de las transacciones de SQL Server.

Por ejemplo, cuando un programa envía un mensaje dentro de una transacción, Service Broker no envía el mensaje a través de la red hasta que el programa confirme la transacción. Cuando un programa recibe un mensaje dentro de una transacción, Motor de base de datos no quita permanentemente el mensaje de la cola hasta que el programa confirme la transacción.

La mensajería transaccional le ayuda a escribir aplicaciones robustas y escalables, ya que asegura que el estado de la base de datos sigue siendo coherente con el estado de las colas. Cuando una aplicación realiza un cambio en la base de datos y envía o recibe un mensaje, el cambio en la base de datos y la operación de la mensajería forman parte de la misma transacción. Si la transacción se revierte, se revierten el cambio en la base de datos y la operación de mensajería. Ambas operaciones tienen éxito o ambas tienen un error. En el modelo de Service Broker, una aplicación utiliza la mensajería transaccional para garantizar que los mensajes enviados por la aplicación reflejan el estado actual de la base de datos.

Para aprovechar la mensajería transaccional al máximo, escriba sus aplicaciones para que las operaciones de la mensajería se produzcan en la misma transacción que las operaciones de base de datos que los mensajes representan. Por ejemplo, una aplicación que procesa una orden recibe el mensaje para la orden y actualiza la base de datos con la orden en una transacción única.

Si la aplicación recibe en su lugar el mensaje en una transacción y actualiza la base de datos en una transacción diferente, un error para actualizar la base de datos crea una situación donde el mensaje ya no existe pero el cambio que el mensaje solicitó no ha tenido lugar. En este caso, la aplicación no se se aprovecha de una de las ventajas principales que proporciona Service Broker. En particular, Service Broker garantiza que todos los mensajes se entregan una vez, en orden, o se notifica al remitente del mensaje con un mensaje de error de Service Broker. Una aplicación que quita permanentemente un mensaje de la cola, pero no procesa el mensaje, como en este ejemplo, interrumpe esta garantía. Sin esta garantía, la aplicación debe contener el código adicional para administrar las posibles incoherencias o correr el riesgo de resultados incorrectos.

Cuando una aplicación procesa un mensaje y no realiza ningún cambio en la base de datos, la garantía se mantiene. El mensaje se ha procesado correctamente. Una aplicación que utiliza Service Broker puede elegir omitir un mensaje, pero la aplicación no debe perderlo inadvertidamente, incluso en casos donde la aplicación pierde la conectividad a la base de datos o se cierra inesperadamente.