Messagerie transactionnelle
La messagerie transactionnelle est la pierre angulaire du modèle de programmation de Service Broker. Toutes les opérations qui font intervenir Service Broker font partie de la transaction active. Service Broker ne valide aucune opération de messagerie tant que la transaction active n'a pas été validée. Si la transaction est annulée, le Moteur de base de données garantit que toutes les opérations de messagerie faisant partie de la transaction sont également annulées. Une application gère les opérations de messagerie dans le cadre de la gestion des transactions SQL Server.
Par exemple, lorsqu'un programme envoie un message dans une transaction, Service Broker n'envoie pas le message sur le réseau tant que le programme n'a pas validé la transaction. Lorsqu'un programme reçoit un message dans une transaction, le Moteur de base de données ne supprime pas définitivement le message de la file d'attente tant que le programme n'a pas validé la transaction.
La messagerie transactionnelle vous permet d'écrire des applications fiables et évolutives car elle garantit la cohérence entre l'état de la base de données et l'état des files d'attente. Lorsqu'une application effectue une modification dans la base de données et envoie ou reçoit un message, la modification apportée à la base de données et l'opération de messagerie font partie de la même transaction. Si la transaction est annulée, la modification de la base de données et l'opération de messagerie sont annulées. Soit les deux opérations réussissent, soit les deux opérations échouent. Dans le modèle de Service Broker, une application utilise la messagerie transactionnelle pour garantir que les messages envoyés par l'application reflètent l'état actuel de la base de données.
Pour tirer pleinement parti de la messagerie transactionnelle, vous écrivez vos applications de sorte que les opérations de messagerie s'opèrent dans la même transaction que les opérations de base de données que les messages représentent. Par exemple, une application qui traite une commande reçoit le message pour la commande et met à jour la base de données avec la commande au sein d'une même transaction.
En revanche, si l'application reçoit le message dans une transaction et met à jour la base de données dans une autre transaction, l'échec de la mise à jour de la base de données crée une situation où le message n'existe plus mais où la modification que le message a demandée n'a pas eu lieu. Dans ce cas, l'application ne tire pas parti de l'un des principaux avantages offerts par Service Broker. Plus spécifiquement, Service Broker garantit que tous les messages sont remis précisément une fois, dans l'ordre, sans quoi, l'expéditeur du message est notifié avec un message d'erreur Service Broker. Une application qui supprime définitivement un message de la file d'attente mais qui ne parvient pas à traiter le message, comme dans cet exemple, ne bénéficie plus de cette garantie. Sans cette garantie, l'application doit contenir du code supplémentaire pour gérer les éventuelles incohérences ; dans le cas contraire, des résultats incorrects sont possibles.
Lorsqu'une application traite un message et n'apporte aucune modification à la base de données, la garantie s'applique toujours. Le message a été correctement traité. Une application qui utilise Service Broker peut choisir d'ignorer un message mais ne doit pas perdre un message par inadvertance, même lorsqu'elle perd la connexion à la base de données ou se ferme de manière inattendue.
Voir aussi