Service Broker Warteschlange Rollbacks auf

Question

erhalten

Als Base auf here

Service Broker bietet eine automatische poison Nachricht Erkennung. Bei der automatischen Erkennung von ungültigen Nachrichten wird der Warteschlangenstatus auf "AUS" gesetzt, wenn eine Transaktion, die Nachrichten aus der Warteschlange empfängt, fünfmal zurücksetzt. Diese Funktion schützt vor katastrophalen Fehlern, die eine Anwendung programmatisch nicht erkennen kann.

Ich habe eine Windows-Dienstanwendung, die SB-Warteschlange abfragt und sie an einen Web-Service-Endpunkt sendet. Da, sollte ich jede "Server goes-off" Probleme behandeln ─get zurück Nachricht an die Warteschlange, so dass ich "Queue-Artikel erhalten" und "Queue Artikel senden" Methoden in die gleiche Transaktion. Bei der allerersten Ausnahme (HttpRequestException) fange ich an, den Server für das vordefinierte Zeitlimit zu pingen, dann fahre fort/schließe das Programm.

Allerdings fünfmal zurückrollen ist ein Problem, ich verstehe, dass unabhängig von der Zeit Lücke zwischen 5 aufeinanderfolgenden Rollbacks es Rollback Anzahl global zählt, so dass die Warteschlange schließlich deaktiviert wird. Habe ich Recht damit? Hat die Warteschlange eine Zeitüberschreitung für das Zurücksetzen der Anzahl der Zurücksetzungen?

Wenn dies das Verhalten ist, ist es besser, "queue item sending" -Methode von der Transaktion auszuschließen? Wenn ich dies tue, sollte ich der Vorgehensweise folgen, die bei einer Ausnahme die Nachricht in einer anderen Ressource (Tabelle, Datei), die später gesendet werden soll, oder anderen Alternativen aufbewahren..

Was ist mit using tables as queues, um meine Transaktion einig und von SB Rollback Problem befreit werden? Wäre es so zuverlässig wie SB?

Answer 1

AFAIK, 5 aufeinanderfolgende Rollbacks der gleichen Nachricht in einer Warteschlange mit POISON_MESSAGE_HANDLING = ON mit deaktivieren die Warteschlange unabhängig von der Zeitlücke.

Haben Sie darüber nachgedacht, die Behandlung von Giftnachrichten einfach für die Warteschlange zu deaktivieren? Die Aufgabe wäre dann in Ihrer Anwendung, zwischen einer echten Giftnachricht (eine, die niemals erfolgreich verarbeitet werden kann) und einem Problem mit einer externen Dienstabhängigkeit zu unterscheiden. Im ersten Fall könnten Sie die Problemmeldung an anderer Stelle protokollieren und anstelle von Rollback festschreiben.

Es gibt andere Muster, die man verwenden könnte, wie das erneute Einreihen der Nachricht und das Festschreiben, aber vieles hängt davon ab, ob Nachrichten in der richtigen Reihenfolge verarbeitet werden müssen.