Transacties en vergrendelingsmodi in Betrouwbare verzamelingen van Azure Service Fabric
Transactie
Een transactie is een reeks bewerkingen die worden uitgevoerd als één logische werkeenheid. Het vertoont de algemene ACID-eigenschappen (atomiciteit, consistentie, isolatie, duurzaamheid) van databasetransacties:
- Atomiciteit: een transactie moet een atomische werkeenheid zijn. Met andere woorden, alle gegevenswijzigingen worden uitgevoerd of geen van deze wijzigingen wordt uitgevoerd.
- Consistentie: Wanneer deze is voltooid, moet een transactie alle gegevens in een consistente status achterlaten. Alle interne gegevensstructuren moeten aan het einde van de transactie correct zijn.
- Isolatie: wijzigingen die door gelijktijdige transacties worden aangebracht, moeten worden geïsoleerd van de wijzigingen die door andere gelijktijdige transacties zijn aangebracht. Het isolatieniveau dat wordt gebruikt voor een bewerking binnen een ITransaction wordt bepaald door de IReliableState die de bewerking uitvoert.
- Duurzaamheid: Nadat een transactie is voltooid, zijn de effecten permanent aanwezig in het systeem. De wijzigingen blijven behouden, zelfs in het geval van een systeemfout.
Isolatieniveaus
Isolatieniveau definieert de mate waarin de transactie moet worden geïsoleerd van wijzigingen die door andere transacties zijn aangebracht. Er zijn twee isolatieniveaus die worden ondersteund in Reliable Collections:
- Herhaalbare leesbewerking: hiermee geeft u op dat instructies geen gegevens kunnen lezen die zijn gewijzigd maar nog niet zijn doorgevoerd door andere transacties en dat er geen andere transacties gegevens kunnen wijzigen die door de huidige transactie zijn gelezen totdat de huidige transactie is voltooid.
- Momentopname: Hiermee geeft u op dat gegevens die worden gelezen door een instructie in een transactie de transactioneel consistente versie is van de gegevens die aan het begin van de transactie bestonden. De transactie kan alleen gegevenswijzigingen herkennen die vóór het begin van de transactie zijn doorgevoerd. Gegevenswijzigingen die door andere transacties na het begin van de huidige transactie zijn aangebracht, zijn niet zichtbaar voor instructies die worden uitgevoerd in de huidige transactie. Het effect is alsof de instructies in een transactie een momentopname krijgen van de vastgelegde gegevens zoals deze bestonden aan het begin van de transactie. Momentopnamen zijn consistent in Reliable Collections.
Betrouwbare verzamelingen kiezen automatisch het isolatieniveau dat moet worden gebruikt voor een bepaalde leesbewerking, afhankelijk van de bewerking en de rol van de replica op het moment dat de transactie wordt gemaakt. Hieronder ziet u de tabel waarin standaardwaarden voor isolatieniveau worden weergegeven voor Reliable Dictionary- en Queue-bewerkingen.
| Bewerking \ rol | Primair | Secundair |
|---|---|---|
| Lezen van één entiteit | Herhaalbare leesbewerking | Momentopname |
| Opsomming, Aantal | Momentopname | Momentopname |
Notitie
Veelvoorkomende voorbeelden voor bewerkingen met één entiteit zijn IReliableDictionary.TryGetValueAsync, IReliableQueue.TryPeekAsync.
Zowel de Reliable Dictionary als de Reliable Queue bieden ondersteuning voor het lezen van uw schrijfbewerkingen. Met andere woorden, elke schrijfbewerking binnen een transactie is zichtbaar voor een volgende leesbewerking die deel uitmaakt van dezelfde transactie.
Vergrendelingen
In Reliable Collections implementeren alle transacties strikte twee fasevergrendelingen: een transactie geeft de vergrendelingen die deze heeft verkregen niet vrij totdat de transactie wordt beëindigd met een afgebroken of een doorvoering.
Reliable Dictionary maakt gebruik van vergrendeling op rijniveau voor alle bewerkingen met één entiteit.
Reliable Queue ruilt gelijktijdigheid af voor strikte transactionele FIFO-eigenschap.
Reliable Queue maakt gebruik van vergrendelingen op bewerkingsniveau waarmee één transactie met TryPeekAsync en/of TryDequeueAsync en één transactie tegelijk mogelijk EnqueueAsync is.
Houd er rekening mee dat fifo behouden moet blijven als een TryPeekAsync of TryDequeueAsync ooit merkt dat de reliable queue leeg is, ze ook worden vergrendeld EnqueueAsync.
Schrijfbewerkingen nemen altijd exclusieve vergrendelingen. Voor leesbewerkingen is de vergrendeling afhankelijk van een aantal factoren:
- Leesbewerkingen die worden uitgevoerd met behulp van isolatie van momentopnamen, zijn vergrendelingsvrij.
- Elke herhaalbare leesbewerking neemt standaard gedeelde vergrendelingen.
- Voor elke leesbewerking die herhaalbare leesbewerkingen ondersteunt, kan de gebruiker echter vragen om een updatevergrendeling in plaats van de gedeelde vergrendeling. Een updatevergrendeling is een asymmetrische vergrendeling die wordt gebruikt om een veelvoorkomende vorm van impasse te voorkomen die optreedt wanneer resources voor potentiële updates op een later tijdstip worden vergrendeld door meerdere transacties.
De compatibiliteitsmatrix voor vergrendelingen vindt u in de volgende tabel:
| Aanvraag \ Verleend | Geen | Gedeeld | Bijwerken | Exclusief |
|---|---|---|---|---|
| Gedeeld | Geen conflict | Geen conflict | Conflict | Conflict |
| Bijwerken | Geen conflict | Geen conflict | Conflict | Conflict |
| Exclusief | Geen conflict | Conflict | Conflict | Conflict |
Het time-outargument in Reliable Collections-API's wordt gebruikt voor impassedetectie. Twee transacties (T1 en T2) proberen bijvoorbeeld K1 te lezen en bij te werken. Het is mogelijk dat ze een impasse hebben, omdat ze allebei de gedeelde vergrendeling hebben. In dit geval treedt er een time-out op voor een of beide bewerkingen. In dit scenario kan een updatevergrendeling een dergelijke impasse voorkomen.