Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a:SQL Server
Instância Gerenciada de SQL do Azure
A base do modelo de programação do Service Broker é o sistema de mensagens transacionais. Qualquer operação que envolva o Service Broker faz parte da transação atual. O Service Broker não confirma uma operação de mensagens até que a transação atual seja confirmada. Se a transação for revertida, o Mecanismo de Banco de Dados garante que todas os operações do sistema de mensagens que fazem parte da transação também sejam revertidas. Um aplicativo gerencia as operações do sistema 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.
O sistema de mensagens transacionais ajuda você a gravar aplicativos sofisticados e escaláveis assegurando que o estado do banco de dados permaneça consistente com o estado das filas. Quando um aplicativo efetua uma alteração no banco de dados e envia ou recebe uma mensagem, a alteração no banco de dados e a operação do sistema de mensagens são parte da mesma transação. Se a transação for revertida, tanto a alteração no banco de dados como a operação do sistema de mensagens são revertidas. As duas operações serão bem-sucedidas ou as duas operações falharão. No modelo do Service Broker, um aplicativo usa o sistema de mensagens transacionais para garantir que as mensagens enviadas pelo aplicativo reflitam o estado atual do banco de dados.
Para aproveitar ao máximo o sistema de mensagens transacionais, você grava os aplicativos assim as operações do sistema de mensagens ocorrem na mesma transação que as operações do banco de dados que as mensagens representam. Por exemplo, um aplicativo que processa uma pedido recebe a mensagem para o pedido e atualiza o banco de dados com o pedido em uma única transação.
Se o aplicativo receber a mensagem em uma transação e atualizar o banco de dados em uma transação diferente, uma falha ao atualizar o banco de dados criará uma situação em que a mensagem não existe mais, mas a alteração solicitada não ocorreu. Nesse caso, o aplicativo não aproveita um dos principais benefícios fornecidos pelo Service Broker. 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 processa a mensagem como neste exemplo, quebra essa garantia. Sem essa garantia, o aplicativo deve conter o código adicional para tratar de possíveis inconsistências ou executar o risco de resultados incorretos.
Quando um aplicativo processa uma mensagem e não faz nenhuma alteração 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 inadvertidamente uma mensagem, mesmo nos casos em que o aplicativo perde a conectividade com o banco de dados ou sai inesperadamente.