sql >> Database >  >> RDS >> Sqlserver

Sql Server Service Broker

Gespreksgroepen zijn lokaal alleen concept, exclusief gebruikt voor vergrendeling:gecorreleerde conversaties horen bij een groep, zodat terwijl u een bericht in een conversatie verwerkt, een andere thread geen gecorreleerd bericht kan verwerken. Er is geen informatie over gespreksgroepen die door de twee eindpunten worden uitgewisseld, dus in uw voorbeeld behoren alle initiatoreindpunten tot één gespreksgroep, maar de doeleindpunten zijn elk een afzonderlijke gespreksgroep (elke groep heeft slechts één gesprek). De reden waarom het systeem zich zo gedraagt, is omdat gespreksgroepen zijn ontworpen om een ​​probleem aan te pakken, zoals bijvoorbeeld een reisboekingsservice:wanneer het een bericht ontvangt om 'een reis te boeken', moet het een vlucht, een hotel en een auto reserveren verhuur. Het moet drie berichten sturen, één naar elk van deze diensten ('vluchten', 'hotels', 'auto's') en dan komen de antwoorden asynchroon terug. Als ze terugkomen, moet de verwerking ervoor zorgen dat ze niet gelijktijdig worden verwerkt door afzonderlijke threads, die elk zouden proberen de status van het 'trip'-record bij te werken. In messaging staat dit probleem bekend als 'berichtcorrelatieprobleem'.

Vaak worden gespreksgroepen echter alleen om prestatieredenen in SSB ingezet:ze maken grotere RECEIVE-resultaten mogelijk. Doeleindpunten kunnen samen in een groep worden verplaatst met behulp van MOVE CONVERSATION maar in de praktijk is er een veel eenvoudiger truc:draai de richting van het gesprek om. Heb je bestemming start de gesprekken (gegroepeerd) en de bron verzendt zijn 'updates' over de conversatie(s) die door de bestemming zijn gestart.

Enkele opmerkingen:

  • Gebruik niet het vuur-en-vergeet-patroon van BEGIN/SEND/END. Je maakt het onmogelijk om in de toekomst een probleem te diagnosticeren, zie Fire and Forget:goed voor het leger, maar niet voor Service Broker-gesprekken .
  • Gebruik nooit WITH CLEANUP in productiecode. Het is bedoeld voor administratieve laatste redmiddelmaatregelen, zoals noodherstel. Als je het misbruikt, ontzeg je SSB elke kans om het bericht correct te volgen voor een correcte bezorging (als het bericht om wat voor reden dan ook op het doel stuitert, zal het voor altijd verloren gaan).
  • SSB garandeert geen volgorde tussen gesprekken, alleen binnen één gesprek. Het starten van een nieuw gesprek voor elke INSERT-gebeurtenis garandeert niet dat de volgorde van invoegbewerkingen behouden blijft.



  1. PreparedStatement en setTimestamp in oracle jdbc

  2. SIN() Functie in Oracle

  3. Zoek de afstand tussen twee punten met behulp van de lengte- en breedtegraad in mysql

  4. KIES * WAAR NIET BESTAAT