Deadlock

Wat is een deadlock?

Een deadlock ontstaat wanneer twee transacties elkaar blokkeren. Transactie A heeft rij 1 vast en wacht op rij 2. Transactie B heeft rij 2 vast en wacht op rij 1. Geen van beide kan verder.

Databases detecteren zo'n kring meestal automatisch. Ze kiezen één transactie als slachtoffer, breken die af en laten de andere doorgaan. De afgebroken transactie moet daarna opnieuw geprobeerd worden.

Een deadlock is dus geen gewone traagheid. Het is een logische blokkade in de volgorde waarin transacties data vastnemen.

Hoe ontstaat een deadlock?

Het klassieke patroon is twee processen die dezelfde tabellen in andere volgorde bijwerken.

-- Transactie A
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

-- Transactie B
UPDATE accounts SET balance = balance - 50 WHERE id = 2;
UPDATE accounts SET balance = balance + 50 WHERE id = 1;

Als A eerst account 1 lockt en B eerst account 2, kan elk daarna wachten op de rij die de ander vasthoudt.

Deadlock versus lock wait

Bij een lock wait wacht één transactie tot een andere klaar is. Dat is normaal gedrag. Zodra de eerste transactie commit of rollback doet, kan de tweede verder.

Bij een deadlock kan niemand verder zonder ingreep, omdat de wachtrij in een cirkel zit. Daarom moet de database één transactie stoppen.

Hoe beperk je deadlocks?

1. Gebruik een vaste volgorde. Werk tabellen en rijen altijd in dezelfde volgorde bij.

2. Hou transacties kort. Doe geen netwerkcalls, gebruikersinteractie of lange berekeningen binnen een open transactie.

3. Indexeer filters goed. Zonder passende index raakt een update soms veel meer rijen dan nodig.

4. Voorzie retries. Een applicatie moet een deadlock kunnen herkennen en de transactie veilig opnieuw proberen.

Deadlocks in data pipelines

Deadlocks komen niet alleen in applicaties voor. Ook batchjobs, ETL-processen en upserts kunnen botsen met operationele processen. Een nachtelijke lading die brede updates doet op tabellen waar overdag gebruikers op werken, kan transacties langer vasthouden dan verwacht.

Daarom horen zware ladingen in een eigen venster, staginglaag of data warehouse, en niet blind op dezelfde tabellen die je operationele systeem nodig heeft.

Waar moet je op letten bij deadlocks

• Los de oorzaak op, niet alleen de foutmelding. Retry is nodig, maar herhaalde deadlocks wijzen op ontwerp of timing.

• Lees de deadlock graph. Die toont welke queries, locks en tabellen betrokken waren.

• Let op brede updates. Eén update zonder goede filter kan veel locks nemen en andere transacties blokkeren.