Gerepliceerde korrels
Soms kunnen er meerdere exemplaren van dezelfde korrel actief zijn, zoals bij het uitvoeren van een multicluster en het gebruik van de OneInstancePerClusterAttribute. De JournaledGrain is ontworpen ter ondersteuning van gerepliceerde exemplaren met minimale wrijving. Het is afhankelijk van providers voor logboekconsistentie om de benodigde protocollen uit te voeren om ervoor te zorgen dat alle exemplaren overeenkomen met dezelfde reeks gebeurtenissen. Het zorgt met name voor de volgende aspecten:
Consistente versies: Alle versies van de graanstatus (met uitzondering van voorlopige versies) zijn gebaseerd op dezelfde globale reeks gebeurtenissen. Met name als twee exemplaren hetzelfde versienummer zien, zien ze dezelfde status.
Racing Events: meerdere exemplaren kunnen tegelijkertijd een gebeurtenis genereren. De consistentieprovider lost deze race op en zorgt ervoor dat iedereen akkoord gaat met dezelfde reeks.
Meldingen/reactiviteit: nadat een gebeurtenis is gegenereerd bij een enkelkorrelig exemplaar, werkt de consistentieprovider niet alleen de opslag bij, maar wordt ook alle andere graanexemplaren op de hoogte gebracht.
Zie ons TechReport- en GSP-document (Global Sequence Protocol) voor een algemene bespreking van de consistentie.
Voorwaardelijke gebeurtenissen
Race-gebeurtenissen kunnen problematisch zijn als ze een conflict hebben, dat wil bijvoorbeeld om een of andere reden niet beide doorvoeren. Wanneer u bijvoorbeeld geld van een bankrekening intrekt, kunnen twee instanties onafhankelijk bepalen of er voldoende geld is voor een intrekking en een intrekkingsevenement uitgeven. Maar de combinatie van beide gebeurtenissen kan worden overschreven. Om dit te voorkomen, ondersteunt de JournaledGrain API een RaiseConditionalEvent methode.
bool success = await RaiseConditionalEvent(
new WithdrawalEvent() { /* ... */ });
Met voorwaardelijke gebeurtenissen controleert u of de lokale versie overeenkomt met de versie in de opslag. Als dat niet het geval is, betekent dit dat de gebeurtenisreeks in de tussentijd is gegroeid, wat betekent dat deze gebeurtenis een race heeft verloren ten opzichte van een andere gebeurtenis. In dat geval wordt de voorwaardelijke gebeurtenis niet toegevoegd aan het logboek en RaiseConditionalEvent wordt onwaar geretourneerd.
Dit is het analogie van het gebruik van e-tags met voorwaardelijke opslagupdates en biedt ook een eenvoudig mechanisme om te voorkomen dat conflicterende gebeurtenissen worden doorgevoerd.
Het is mogelijk en verstandig om zowel voorwaardelijke als onvoorwaardelijke gebeurtenissen voor hetzelfde graan te gebruiken, zoals een DepositEvent en een WithdrawalEvent. Stortingen hoeven niet voorwaardelijk te zijn: zelfs als een DepositEvent race verliest, hoeft deze niet te worden geannuleerd, maar kan nog steeds worden toegevoegd aan de globale gebeurtenisvolgorde.
Wachtend op de door de geretourneerde RaiseConditionalEvent taak is voldoende om de gebeurtenis te bevestigen, dus het is niet nodig om ook aan te roepen ConfirmEvents.
Expliciete synchronisatie
Soms is het wenselijk om ervoor te zorgen dat een graan volledig wordt opgepikt met de nieuwste versie. Dit kan worden afgedwongen door het volgende aan te roepen:
await RefreshNow();
Dit doet twee dingen:
- Alle niet-bevestigde gebeurtenissen worden bevestigd.
- De nieuwste versie wordt geladen vanuit de opslag.
