Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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:
Herhaalbaar lezen: Hiermee specificeert u dat instructies geen gegevens kunnen lezen die zijn gewijzigd maar nog niet door andere transacties zijn gecommitteerd, en dat geen andere transacties gegevens kunnen wijzigen die door de huidige transactie zijn gelezen totdat de huidige transactie is afgerond.
- Voordelen van leesbare herhaalbare transacties:
- Lagere geheugenvoetafdruk dan momentopnametransacties
- Zorgt voor een consistente retournering van waarden voor meerdere leesbewerkingen op een bepaald moment
- Overwegingen voor leesbare transacties:
Schrijfbewerkingen worden geblokkeerd terwijl er een actieve leesbewerking van de gegevens is
Leesbewerkingen worden ook geblokkeerd terwijl er een actieve schrijfbewerking van de gegevens is.
- Voordelen van leesbare herhaalbare transacties:
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 zijn doorgevoerd vóór de eerste leesbewerking van de transactie. 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 dat het lijkt alsof de statements in een transactie een momentopname krijgen van de vastgelegde gegevens zoals die bestonden aan het begin van de transactie. Momentopnamen zijn consistent binnen Reliable Collections.
- Voordelen van momentopnametransacties:
- Staat schrijfbewerkingen toe, zelfs wanneer een waarde is gelezen in een niet-verzonden transactie
- Overwegingen voor momentopnametransacties:
- Langdurige momentopnametransacties kunnen leiden tot een grote geheugenvoetafdruk voor de service, omdat er meer waarden naar het geheugen worden verplaatst om de isolatie van momentopnamen te behouden
- Verschillende transacties kunnen verschillende waarden retourneren voor leesgegevens, afhankelijk van wanneer de momentopname is gemaakt
- Voordelen van momentopnametransacties:
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.
| Operatie \ rol | Primair | Secundair |
|---|---|---|
| Lezen van één entiteit | Herhaalbare leesbewerking | Momentopname |
| Opsomming, Aantal | Momentopname | Momentopname |
Opmerking
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.
Voorbeeld van herhaalbaar leesgedrag
In dit voorbeeld ziet u dat T2 wordt verhinderd een vergrendeling op K1 te verkrijgen totdat T1 commit of bevestigt, omdat T1 momenteel een leesvergrendeling op de sleutel heeft.
Voorbeeld van het gedrag van momentopnamen
In dit voorbeeld ziet u dat hoewel T2 de waarde van K1 naar V6 heeft bijgewerkt, T2 K1 nog steeds als V1 opsomt, terwijl het zich wel bewust is van zijn eigen wijziging in K2. T3 wordt niet beïnvloed omdat hiermee sleutels worden gelezen die geen huidige schrijfvergrendelingen hebben.
Sloten
In Betrouwbare collecties implementeren alle transacties strikte twee-fasevergrendeling: een transactie geeft de vergrendelingen die deze heeft verkregen niet vrij totdat de transactie wordt beëindigd met ofwel afbreken of een commit.
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 zodat één transactie met TryPeekAsync en/of TryDequeueAsync en één transactie met EnqueueAsync tegelijk mogelijk is.
Houd er rekening mee dat als u FIFO wilt behouden, als een TryPeekAsync of TryDequeueAsync ooit merkt dat de betrouwbare wachtrij leeg is, ze ook EnqueueAsync vergrendelen.
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 \ Toegewezen | 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 deadlock ervaren, 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.