Transaktionales Messaging
Transaktionales Messaging bildet die Grundlage des Service Broker-Programmiermodells. Jeder Vorgang, an dem Service Broker beteiligt ist, ist Teil der aktuellen Transaktion. Service Broker führt einen Commit für einen Messagingvorgang erst aus, nachdem ein Commit für die aktuelle Transaktion ausgeführt wurde. Wenn ein Rollback für die Transaktion ausgeführt wird, garantiert Database Engine (Datenbankmodul), dass auch ein Rollback für alle Messagingvorgänge ausgeführt wird, die Teil der Transaktion sind. Eine Anwendung verwaltet Messagingvorgänge im Rahmen der Verwaltung von SQL Server-Transaktionen.
Wenn ein Programm beispielsweise in einer Transaktion eine Nachricht sendet, wartet Service Broker mit dem Versand der Nachricht über das Netzwerk, bis das Programm einen Commit für die Transaktion ausgeführt hat. Empfängt ein Programm in einer Transaktion eine Nachricht, entfernt Database Engine (Datenbankmodul) die Nachricht erst permanent aus der Warteschlange, nachdem das Programm einen Commit für die Transaktion ausgeführt hat.
Transaktionales Messaging unterstützt Sie beim Schreiben robuster, skalierbarer Anwendungen, indem es sicherstellt, dass der Status der Datenbank und der Status der Warteschlangen aufeinander abgestimmt bleiben. Wenn eine Anwendung eine Änderung an der Datenbank vornimmt und eine Nachricht sendet oder empfängt, sind die Datenbankänderung und der Messagingvorgang Teil derselben Transaktion. Wird ein Rollback für die Transaktion ausgeführt, so wird auch ein Rollback für die Datenbankänderung und den Messagingvorgang ausgeführt. Entweder sind beide Vorgänge erfolgreich, oder beide Vorgänge schlagen fehl. Im Service Broker-Modell gewährleistet eine Anwendung mithilfe von transaktionalem Messaging, dass die von ihr gesendeten Nachrichten den aktuellen Status der Datenbank widerspiegeln.
Sie können die Vorteile des transaktionalen Messagings in vollem Umfang nutzen, indem Sie die Anwendungen so schreiben, dass die Messagingvorgänge in derselben Transaktion stattfinden wie die Datenbankvorgänge, die durch die Nachrichten dargestellt werden. Beispielsweise empfängt eine Anwendung, die einen Auftrag verarbeitet, die Nachricht für den Auftrag und aktualisiert die Datenbank mit dem Auftrag in einer einzigen Transaktion.
Falls die Anwendung hingegen in einer Transaktion die Nachricht empfängt und in einer anderen Transaktion die Datenbank aktualisiert, führt ein Fehler bei der Datenbankaktualisierung zu einer Situation, in der die Nachricht nicht mehr vorhanden ist, die von der Nachricht angeforderte Änderung jedoch nicht stattgefunden hat. In diesem Fall nutzt die Anwendung einen der Hauptvorteile von Service Broker nicht aus. Service Broker garantiert vor allem, dass sämtliche Nachrichten der Reihe nach genau ein Mal übermittelt werden. Andernfalls wird der Nachrichtenabsender durch eine Service Broker-Fehlermeldung benachrichtigt. Eine Anwendung, die eine Nachricht permanent aus der Warteschlange entfernt, diese Nachricht aber wie in diesem Beispiel nicht verarbeitet, hebt diese Garantie auf. Ohne diese Garantie muss die Anwendung zusätzlichen Code zur Behandlung möglicher Inkonsistenzen enthalten, oder es besteht das Risiko falscher Ergebnisse.
Wenn eine Anwendung eine Nachricht verarbeitet und keine Änderungen an der Datenbank vornimmt, bleibt die Garantie bestehen. Dies bedeutet, dass die Nachricht erfolgreich verarbeitet wurde. In einer Anwendung, die Service Broker verwendet, wird eine Nachricht zwar möglicherweise ignoriert, doch selbst wenn die Anwendung die Verbindung zur Datenbank verliert oder unerwartet beendet wird, dürfen Nachrichten nicht unbeabsichtigterweise verloren gehen.