Sql Server Service Broker: Wie strukturiert man Konversationen für ein einfaches Warteschlangen-Szenario?

Question

Ich bin ein Sql Server Service Broker-Neuling und ich versuche, den besten Weg, um Service Broker für einen (scheinbar) einfachen Anwendungsfall einrichten zu erfassen: Ich möchte eine einfache Arbeitswarteschlange erstellen, in der eine Anwendung Arbeitselemente in die Warteschlange ablegt und eine andere Anwendung Arbeitselemente aus dieser Warteschlange aufnimmt und verarbeitet. Es besteht keine Notwendigkeit für die erste Anwendung, Statusmeldungen von der zweiten Anwendung zurückzubekommen. Ich möchte, dass die Warteschlange in einer einzigen Sql Server-Instanz läuft.

Was mich am meisten verwirrt, ist die Frage, wie sich Gespräche/Dialoge auf diese Situation beziehen. Ich weiß, dass man Nachrichten nur im Rahmen einer Unterhaltung/eines Dialogs senden/empfangen kann, aber da es kein Hin- und Hergeplapper zwischen den beiden Anwendungen gibt, weiß ich nicht, wann der richtige Zeitpunkt ist, um eine neue Unterhaltung zu beginnen. Die beiden extremen Alternativen scheinen zu sein:

• Jedes Mal, wenn ich ein Workitem in die Warteschlange stelle, beginne ich ein neues Gespräch. Jede Konversation enthält also genau eine Nachricht.
• Zum Zeitpunkt der Bereitstellung erstelle ich manuell ein einzelnes Gespräch mit unendlicher Lebensdauer. Wenn es an der Zeit ist, ein Workitem in die Warteschlange zu stellen, sende ich es immer als Teil dieser einzigen Konversation.

Was wären die Konsequenzen, wenn Sie einen dieser Wege einschlagen würden?

Auch im ersten Fall scheint es, wie ich einige END CONVERSATIONs tun müssen, um für Sql Server in der Lage, Ressourcen intern zu bereinigen. Gibt es eine Anleitung dafür, wann der richtige Ort wäre, um diese zu setzen? (Oder ist es möglicherweise besser, sich darauf zu verlassen, dass die Unterhaltungen irgendwann beendet werden?)

Answer 1

Sie sollten mit jedem Arbeitsschritt ein eigenes Gespräch beginnen. Der Produzent (Initiator) beginnt einen Dialog und sendet die Nachricht, in der das Workitem beschrieben wird, und überträgt sie dann. Der Konsument (Ziel) empfängt die Nachricht (oder wird aktiviert), prüft die Nutzlast, um die Details des Workitems zu verstehen, führt die Arbeit aus und beendet dann den Dialog und die Übertragung. Die resultierende EndDialog-Nachricht wird an die Initiator-Warteschlange zurückgeschickt, und eine aktivierte Prozedur in der Initiator-Warteschlange antwortet darauf, indem sie den Dialog auf der Initiatorseite beendet.

Dies ist die einfachste Lösung, und wenn Sie sie zum Laufen bringen, haben Sie eine solide Grundlage, auf der Sie aufbauen können. Sparen Sie nicht am falschen Ende und beenden Sie den Dialog auf der Seite des Initiators, wenn der Produzent das Workitem in die Warteschlange stellt. fire-and-forget und hat mehrere Nachteile .

Wenn Sie hohe Leistungsanforderungen haben (über 200 Anfragen pro Sekunde), müssen Sie die Konversationen expliziter verwalten. Ich habe einen Blogeintrag über Wiederverwendung von Konversationen aus Leistungsgründen . Auf der Empfangsseite empfehle ich die Lektüre Schreiben von Service-Broker-Prozeduren .

Ich habe auch einen Blogeintrag, der ziemlich genau das tut, was Sie brauchen, obwohl er keine Arbeitsaufgaben plant, sondern stattdessen eine benutzerdefinierte Prozedur auslöst: Asynchrone Ausführung von Prozeduren .

Wenn Sie sich entscheiden, die Workitems aus einem aktivierten Kontext zu konsumieren und so die netten Selbstausgleichsfähigkeiten der Aktivierung zu nutzen, dann müssen Sie den EXECUTE AS-Kontext zu verstehen, in dem die Aktivierung erfolgt .