Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a:
SQL ServerAzure SQL Managed Instance
A base do modelo de programação do Service Broker é a mensagem transacional. Qualquer operação que envolva o Service Broker faz parte da transação atual. O Service Broker não confirma uma operação de mensagem até que a transação atual seja confirmada. Se a transação for revertida, o Mecanismo de Banco de Dados garante que todas as operações de mensagens que fazem parte da transação também sejam revertidas. Um aplicativo gerencia operações de mensagens como parte do gerenciamento de transações do SQL Server.
Por exemplo, quando um programa envia uma mensagem dentro de uma transação, o Service Broker não envia a mensagem pela rede até que o programa confirme a transação. Quando um programa recebe uma mensagem dentro de uma transação, o Mecanismo de Banco de Dados não remove permanentemente a mensagem da fila até que o programa confirme a transação.
As mensagens transacionais ajudam a escrever aplicativos robustos e escaláveis, garantindo que o estado do banco de dados permaneça consistente com o estado das filas. Quando um aplicativo faz uma alteração no banco de dados e envia ou recebe uma mensagem, a alteração no banco de dados e a operação de mensagens fazem parte da mesma transação. Se a transação for revertida, tanto a alteração no banco de dados quanto a operação de mensagens serão revertidas. Ambas as operações são bem-sucedidas ou ambas falham. No modelo do Service Broker, um aplicativo usa mensagens transacionais para garantir que as mensagens enviadas pelo aplicativo reflitam o estado atual do banco de dados.
Para tirar o máximo proveito das mensagens transacionais, você escreve seus aplicativos para que as operações de mensagens ocorram na mesma transação que as operações de banco de dados que as mensagens representam. Por exemplo, um aplicativo que processa um pedido recebe a mensagem para o pedido e atualiza o banco de dados com o pedido em uma única transação.
Se, em vez disso, o aplicativo receber a mensagem em uma transação e atualizar o banco de dados em uma transação diferente, uma falha na atualização do banco de dados criará uma situação em que a mensagem não existe mais, mas a alteração solicitada pela mensagem não ocorreu. Nesse caso, o aplicativo não aproveita um dos principais benefícios que o Service Broker oferece. Em particular, o Service Broker garante que todas as mensagens sejam entregues exatamente uma vez, em ordem, ou que o remetente da mensagem seja notificado com uma mensagem de erro do Service Broker. Um aplicativo que remove uma mensagem da fila permanentemente, mas não consegue processar a mensagem como neste exemplo, quebra essa garantia. Sem essa garantia, o aplicativo deve conter código adicional para lidar com possíveis inconsistências ou correr o risco de resultados incorretos.
Quando um aplicativo processa uma mensagem e não faz alterações no banco de dados, a garantia é mantida. A mensagem foi processada com êxito. Um aplicativo que usa o Service Broker pode optar por ignorar uma mensagem, mas o aplicativo não deve perder uma mensagem inadvertidamente, mesmo nos casos em que o aplicativo perde a conectividade com o banco de dados ou sai inesperadamente.