Onmiddellijke en vertraagde bevestigingen

In dit artikel leert u de verschillen tussen onmiddellijke en vertraagde bevestigingen.

Onmiddellijke bevestiging

Voor veel toepassingen willen we ervoor zorgen dat gebeurtenissen onmiddellijk worden bevestigd, zodat de persistente versie niet achterloopt bij de huidige versie in het geheugen en we het risico lopen niet de meest recente status te verliezen als het graan moet mislukken. We kunnen dit garanderen door de volgende regels te volgen:

1. Bevestig alle RaiseEvent aanroepen die worden gebruikt ConfirmEvents voordat de graanmethode wordt geretourneerd.
2. Zorg ervoor dat taken die zijn geretourneerd door RaiseConditionalEvent voltooid voordat de graanmethode wordt geretourneerd.
3. Vermijd ReentrantAttribute of AlwaysInterleaveAttribute kenmerken, zodat slechts één aanroep per keer kan worden verwerkt.

Als we deze regels volgen, betekent dit dat nadat een gebeurtenis is gegenereerd, geen andere graancode kan worden uitgevoerd totdat de gebeurtenis naar de opslag is geschreven. Daarom is het onmogelijk om inconsistenties te observeren tussen de versie in het geheugen en de versie in de opslag. Hoewel dit vaak precies wat we willen, heeft het ook een aantal potentiële nadelen.

Mogelijke nadelen

• Als de verbinding met een extern cluster of opslag tijdelijk wordt onderbroken, wordt het graan niet meer beschikbaar: in feite kan de korrel geen code uitvoeren terwijl deze blijft hangen om de gebeurtenissen te bevestigen, wat voor onbepaalde tijd kan duren (het logboekconsistentieprotocol blijft proberen totdat de opslagverbinding is hersteld).

• Bij het verwerken van veel updates voor één graanexemplaren kan het bevestigen dat ze één voor één inefficiënt worden, bijvoorbeeld waardoor de doorvoer slecht verloopt.

Vertraagde bevestiging

Om de beschikbaarheid en doorvoer in de bovenstaande situaties te verbeteren, kunnen korrels ervoor kiezen om een of beide van de volgende handelingen uit te voeren:

• Sta graanmethoden toe om gebeurtenissen te genereren zonder te wachten op bevestiging.
• Sta reentrancy toe, zodat het graan nieuwe oproepen kan blijven verwerken, zelfs als eerdere oproepen vastlopen op bevestiging.

Dit betekent dat graancode kan worden uitgevoerd terwijl sommige gebeurtenissen nog steeds worden bevestigd. De JournaledGrain<TGrainState,TEventBase> API heeft een aantal specifieke bepalingen om ontwikkelaars nauwkeurige controle te geven over het omgaan met niet-bevestigde gebeurtenissen die zich momenteel in de vlucht bevinden.

De volgende eigenschap kan worden onderzocht om erachter te komen welke gebeurtenissen momenteel niet zijn bevestigd:

IEnumerable<EventType> UnconfirmedEvents { get; }

Omdat de status die door de JournaledGrain<TGrainState,TEventBase>.State eigenschap wordt geretourneerd, niet het effect van niet-bevestigde gebeurtenissen bevat, is er ook een alternatieve eigenschap

StateType TentativeState { get; }

Dit retourneert een "voorlopig" status, verkregen van "Staat" door alle niet-bevestigde gebeurtenissen toe te passen. De voorlopige status is in wezen een 'beste schatting' op wat waarschijnlijk de volgende bevestigde status wordt nadat alle niet-bevestigde gebeurtenissen zijn bevestigd. Er is echter geen garantie dat het daadwerkelijk zal mislukken, omdat het graan kan mislukken, of omdat de gebeurtenissen kunnen racen tegen andere gebeurtenissen en verliezen, waardoor ze worden geannuleerd (als ze voorwaardelijk zijn) of op een latere positie in de volgorde worden weergegeven dan verwacht (als ze onvoorwaardelijke zijn).

Gelijktijdigheidsgaranties

Houd er rekening mee dat Orleans planning op basis van turn-based (coöperatieve gelijktijdigheid) altijd van toepassing is, zelfs wanneer u reentrancy of vertraagde bevestiging gebruikt. Dit betekent dat hoewel er meerdere methoden worden uitgevoerd, er slechts één actief kan worden uitgevoerd. Alle andere zijn vastgelopen in een wacht, dus er zijn nooit echte races die worden veroorzaakt door parallelle threads.

Houd er met name rekening mee dat:

• De eigenschappenState, TentativeStateen VersionUnconfirmedEvents kunnen tijdens de uitvoering van een methode worden gewijzigd.
• Maar dergelijke wijzigingen kunnen alleen optreden terwijl ze vastzitten in een wacht.

Deze garanties gaan ervan uit dat de gebruikerscode binnen de aanbevolen praktijk blijft met betrekking tot taken en async/await (met name gebruikt geen threadpooltaken of gebruikt deze alleen voor code die geen korrelfunctionaliteit aanroept en die correct worden gewacht).