Antwoord

In SQL stellen transacties u in staat om meerdere bewerkingen (insert/update/delete) te groeperen in een enkele atomische werkeenheid die ofwel volledig kan worden toegepast of volledig kan worden teruggedraaid. De levenscyclus van een transactie is opgebouwd uit de volgende opdrachten:

• BEGIN of START TRANSACTION — begin van de transactie;
• COMMIT — bevestiging van de wijzigingen;
• ROLLBACK — terugdraaiing van alle wijzigingen binnen de transactie.

SQL ondersteunt isolatieniveaus voor transacties (Read Uncommitted, Read Committed, Repeatable Read, Serializable), die de zichtbaarheid van gegevens tussen parallelle transacties definiëren en beschermen tegen problemen zoals "vuile leesoperaties" of "spookrijen".

Om de integriteit van de gegevens te waarborgen, zijn de volgende maatregelen nodig:

• Keuze van isolatieniveau (bijvoorbeeld voor bankapplicaties — waarschijnlijk Serializable).
• Expliciet beheer van transacties, vooral wanneer één entiteit gelijktijdig wordt bewerkt (bijvoorbeeld SELECT ... FOR UPDATE).

Voorbeeld in PostgreSQL:

BEGIN;

-- Verkrijg en blokkeer de rij van het product
SELECT * FROM inventory WHERE id = 1 FOR UPDATE;

UPDATE inventory SET quantity = quantity - 1 WHERE id = 1;

COMMIT;

Vragen met een addertje onder het gras

Wat is het standaard isolatieniveau in populaire DBMS (PostgreSQL, MySQL) en hoe verschilt het van SERIALIZABLE?

Antwoord:
In PostgreSQL is het standaard isolatieniveau Read Committed — hierin ziet de transactie alleen de gegevens die zijn bevestigd op het moment van de aanvraag, maar er kunnen "niet-herhaalbare leesoperaties" (non-repeatable reads) voorkomen.
In MySQL (InnoDB) — Repeatable Read. Het verschil met Serializable is dat alleen de laatste volledig alle spook- of parallelle wijzigingen voorkomt, maar aanzienlijk langzamer werkt door wereldwijde vergrendelingen.

Voorbeeld:

-- In Repeatable Read kan SELECT dezelfde rijen retourneren, terwijl in Read Committed nieuwe rijen kunnen verschijnen tussen twee SELECT-query's binnen de transactie.

---

Geschiedenis

In een groot financieel systeem traden er tijdens massale overboekingen tussen rekeningen bij een laag isolatieniveau (Read Committed) af en toe situaties op waarbij hetzelfde saldo gelijktijdig door meerdere transacties werd gebruikt. Dit leidde tot dubbele uitgaven (racecondition). Na de overstap naar Serializable en adequaat beheer van vergrendelingen verdween het probleem.

---

Geschiedenis

In de e-commerce leidde een transactie met UPDATE product SET stock = stock - 1 zonder deze in een transactie te verpakken tot de verkoop van meer producten dan er op voorraad waren. Het probleem kwam alleen aan het licht bij een groot aantal concurrerende bestellingen. Oplossing — gebruik transacties en blokkeer rijen via SELECT ... FOR UPDATE.

---

Geschiedenis

In een logistiek systeem vergat men bij frequente updates een expliciete commit uit te voeren in één van de tabellen. Bij storingen gingen sommige gegevens verloren door autocommit of een onjuiste rollback. Resultaat — verlies van records en kostbare audits.