SQL Server Service Broker: Strukturieren von Gesprächen für ein einfaches Warteschlangenszenario

Ich bin ein SQL Server Service Broker-Neuling und versuche, den besten Weg zu finden, um Service Broker für einen (scheinbar) einfachen Anwendungsfall einzurichten: Ich möchte eine einfache Arbeitswarteschlange erstellen, in der eine Anwendung Arbeitselemente in die ablegt Die Warteschlange und die separate Anwendung nehmen Arbeitselemente aus dieser Warteschlange auf und verarbeiten sie. Die erste Anwendung muss keine Statusmeldungen von der zweiten zurückerhalten. Ich möchte die Warteschlange in einer einzigen SQL Server-Instanz leben.

Was mich am meisten verwirrt, ist, wie Gespräche / Dialoge sich auf diese Situation beziehen. Ich weiß, dass Sie Nachrichten nur im Kontext einer Konversation / eines Dialogs senden / empfangen können, aber da zwischen den beiden Anwendungen kein Hin- und Her-Geschwätz besteht, ist es mir unangenehm, wann der richtige Zeitpunkt für die Erstellung einer neuen Konversation ist. Die beiden extremen Alternativen scheinen zu sein:

Jedes Mal, wenn ich ein Arbeitselement in die Warteschlange stelle, beginne ich eine neue Konversation. In jedem Gespräch ist also genau eine Nachricht enthalten.Zur Bereitstellungszeit erstelle ich manuell eine einzelne Konversation mit unbegrenzter Lebensdauer. Wenn es Zeit ist, ein Arbeitselement in die Warteschlange zu stellen, sende ich es immer als Teil dieser einzelnen Konversation.

Was wären die Konsequenzen einer dieser Routen?

Im ersten Fall muss ich anscheinend einige END CONVERSATIONs ausführen, damit SQL Server Ressourcen intern bereinigen kann. Gibt es eine Anleitung, wann der richtige Ort wäre, um diese einzutragen? (Oder ist es möglicherweise besser, sich darauf zu verlassen, dass das Zeitlimit für die Gespräche überschritten wird?)

Antworten auf die Frage(2)

Ihre Antwort auf die Frage