Deadlocks, locking en MVCC

Isolatieniveaus zijn de belofte; vergrendeling en MVCC zijn de mechanismen die deze belofte waarmaken. Interviewers vragen hiernaar om te zien of je begrijpt wat er onder de motorkap gebeurt wanneer transacties met elkaar botsen.

Er zijn twee brede strategieën:

• Pessimistisch (vergrendeling): conflicterende toegang blokkeren totdat een vergrendeling wordt vrijgegeven.
• Optimistisch / MVCC: iedereen een consistente momentopname laten lezen en conflicten bij het vastleggen detecteren.

Deze les behandelt vergrendelingen, deadlocks en MVCC, plus de afwegingen ertussen.

Bij klassieke vergrendeling worden twee hoofdmodi gebruikt:

• Gedeelde (S-)vergrendeling voor lezingen. Veel transacties kunnen tegelijkertijd een gedeelde vergrendeling op dezelfde rij hebben.
• Exclusieve (X-)vergrendeling voor schrijfbewerkingen. Slechts één transactie kan deze hebben en ze blokkeert alle andere vergrendelingen op die rij.

De regel is: S is compatibel met S, maar X is nergens mee compatibel. Een transactie die schrijft moet wachten tot alle lezers klaar zijn, en lezers moeten wachten op een transactie die schrijft.

Je kunt een schrijfvergrendeling aanvragen voor rijen die je alleen leest, zodat anderen ze niet kunnen wijzigen voordat je handelt. Dit is de standaardmanier om verloren wijzigingen te voorkomen in een lees-wijzig-schrijfcyclus.

SELECT ... FOR UPDATE neemt exclusieve rijvergrendelingen; de rijen blijven vergrendeld totdat je COMMIT of ROLLBACK uitvoert.

Een deadlock ontstaat wanneer twee of meer transacties elk een vergrendeling vasthouden die de andere nodig heeft. Zo ontstaat een cyclus waarin geen enkele transactie verder kan.

Het schoolboekvoorbeeld: T1 vergrendelt rij A en wil daarna rij B; T2 vergrendelt rij B en wil daarna rij A. Beide wachten voor altijd op de andere.

Databases detecteren dit met een wachtgrafiek. Zodra een cyclus wordt gevonden, kiest de engine een slachtoffer en breekt die transactie af. De overige transacties krijgen een deadlockfout en kunnen doorgaan.

Let op hoe de volgorde van vergrendelen elkaar kruist. T1 vergrendelt rij 1 en vraagt daarna rij 2 aan; T2 vergrendelt rij 2 en vraagt daarna rij 1 aan. Geen van beide geeft de vergrendeling vrij, dus de engine breekt één transactie af.

De afgebroken transactie krijgt een fout zoals deadlock detected en moet het opnieuw proberen. De overblijvende transactie wordt normaal vastgelegd.

Je kunt deadlocks niet volledig uitsluiten, maar je kunt ze wel zeldzaam maken. Standaardantwoorden in sollicitatiegesprekken:

• Vaste volgorde van vergrendelen: vergrendel rijen altijd in dezelfde volgorde (bijvoorbeeld met oplopende id). Zo doorbreek je de cyclus.
• Houd transacties kort: houd vergrendelingen zo kort mogelijk vast.
• Verlaag de isolatie als dat veilig is: minder vergrendelingen betekent minder conflicten.
• Voeg logica voor opnieuw proberen toe: slachtoffers van deadlocks moeten automatisch opnieuw proberen.

Een vaste volgorde is de meest effectieve oplossing en het eerste wat interviewers willen horen.

Vergrendelingen kunnen verschillende bereiken hebben, wat een afweging vormt tussen gelijktijdigheid en beheerkosten:

• Vergrendelingen op rijniveau staan een hoge gelijktijdigheid toe, maar kosten meer om te beheren.
• Vergrendelingen op pagina- of tabelniveau zijn goedkoper om bij te houden, maar blokkeren meer transacties.

Sommige engines schalen vergrendelingen op van rijniveau naar tabelniveau wanneer een transactie te veel rijen aanraakt (opschaling van vergrendelingen). Als je dit weet, begrijp je waarom een grote bulk-UPDATE plotseling iedereen kan blokkeren.

MVCC (concurrencycontrole met meerdere versies) is de manier waarop Postgres, Oracle en InnoDB de meeste leesvergrendelingen vermijden. In plaats van te vergrendelen, bewaart de database meerdere versies van elke rij.

Het belangrijkste voordeel, en een veelgebruikte formulering in sollicitatiegesprekken: lezers blokkeren schrijvers niet, en schrijvers blokkeren lezers niet.

Elke transactie ziet een consistente momentopname op een bepaald moment, terwijl schrijvers nieuwe rijversies maken in plaats van rijen ter plekke te overschrijven.

Wanneer een rij wordt gewijzigd, schrijft MVCC een nieuwe versie en bewaart het de oude. Elke versie bevat metagegevens met een transactie-id (in Postgres zijn dat xmin en xmax) die aangeven wanneer de versie zichtbaar werd en wanneer ze werd vervangen.

De momentopname van een transactie bepaalt welke versie deze ziet. Oude versies die geen enkele transactie meer kan zien, worden dode tupels en later door een opruimproces vrijgemaakt. In Postgres heet dat proces VACUUM; als je het niet uitvoert, ontstaat overmatige tabelgroei, een veelgestelde vervolgvraag.

Vat de vergelijking bondig samen:

• Alleen vergrendeling: eenvoudige correctheid, maar lezers en schrijvers blokkeren elkaar, wat de gelijktijdigheid schaadt.
• MVCC: uitstekende gelijktijdigheid bij lezen, zonder leesvergrendelingen, maar met kosten voor versieopslag en opruimen (VACUUM, overmatige groei); voor conflicten tussen schrijfbewerkingen zijn nog steeds vergrendelingen nodig.

Ook engines met MVCC gebruiken vergrendelingen bij schrijfbewerkingen: twee transacties die dezelfde rij wijzigen, moeten na elkaar worden uitgevoerd. MVCC neemt de conflicten tussen lezers en schrijvers weg, maar niet die tussen schrijvers onderling.

Naast MVCC op engineniveau voegen applicaties vaak optimistische vergrendeling toe voor lees-wijzig-schrijfbewerkingen tijdens lange gebruikerssessies. Je voegt een kolom version toe, leest die en eist bij een wijziging dat de versie overeenkomt, waarna je deze verhoogt.

Als een andere transactie de rij eerder heeft gewijzigd, komt de versie niet meer overeen, worden nul rijen gewijzigd en weet je code dat de rij opnieuw moet worden geladen en dat het opnieuw moet worden geprobeerd. Er worden geen vergrendelingen vastgehouden terwijl de gebruiker nadenkt, dus de gelijktijdigheid blijft hoog. Interviewers waarderen dit als antwoord op de vraag: "hoe ga je om met twee gebruikers die hetzelfde record bewerken?"

Je kunt nu het mechanisme achter isolatie uitleggen:

• Gedeelde/exclusieve vergrendelingen coördineren de toegang; SELECT FOR UPDATE neemt expliciete schrijfvergrendelingen.
• Deadlocks zijn vergrendelingscycli; de engine breekt een slachtoffer af en een vaste volgorde van vergrendelen voorkomt de meeste ervan.
• MVCC bewaart rijversies zodat lezers en schrijvers elkaar niet blokkeren, ten koste van opruimwerk (VACUUM, overmatige groei).

Combineer deze mechanismen met de isolatieniveaus en anomalieën uit eerdere lessen, dan kun je een volledig sollicitatiegesprek over gelijktijdigheid van begin tot eind aan.