Antwoord.

Geschiedenis van de vraag

Met de komst van multi-user databases ontstond de uitdaging om gelijktijdige wijzigingen van dezelfde gegevens te beperken. Dit leidde tot de ontwikkeling van verschillende vergrendelingsmechanismen (lock management) die parallelle wijzigingen voorkomen en helpen de integriteit van gegevens te waarborgen.

Probleem

Zonder toegangsinformatie kunnen gelijktijdige operaties leiden tot beschadiging of verlies van gegevens: bijvoorbeeld wanneer twee transacties tegelijkertijd dezelfde rij bijwerken, en de wijzigingen van de ene transactie verloren gaan. Onvoldoende strikte vergrendelingen leiden tot concurrentieproblemen (race conditions), terwijl een teveel aan vergrendelingen leidt tot prestatieverlies (deadlocks, contention).

Oplossing

Moderne databasesystemen hebben vergrendelingsniveaus (row-level, page-level, table-level) en verschillende modi (shared, exclusive, update). De programmeur kan hiermee omgaan via transactie-isolatie-instellingen en expliciete vergrendelingscommando's (bijvoorbeeld SELECT ... FOR UPDATE).

Voorbeeldcode:

-- Vergrendel de rij tot de transactie is voltooid
BEGIN TRANSACTION;
SELECT * FROM users WHERE id = 1 FOR UPDATE;
UPDATE users SET name = 'New Name' WHERE id = 1;
COMMIT;

Belangrijke kenmerken:

Granulariteit van vergrendeling (rij, pagina, tabel)
Expliciete en impliciete vergrendelingen (via transacties en speciale instructies)
Invloed van het isolatieniveau op het vergrendelingsschema

Misleidende vragen.

Wat is het verschil tussen een leesslot (shared lock) en een schrijfslot (exclusive lock)?

Een shared lock stelt meerdere transacties in staat om gegevens tegelijkertijd te lezen, maar niet te wijzigen. Een exclusive lock staat slechts één transactie toe om de gegevens te wijzigen, terwijl alle anderen geen toegang hebben.

Kan een SELECT-opdracht een vergrendeling veroorzaken?

Normaal gesproken veroorzaakt SELECT geen vergrendelingen, maar wanneer je SELECT ... FOR UPDATE gebruikt of bij een hoog isolatieniveau (bijvoorbeeld SERIALIZABLE), kan de database rijen vergrendelen.

Voorbeeldcode:

SELECT * FROM products WHERE id = 10 FOR UPDATE;

Beschermen vergrendelingen altijd tegen "verloren updates"?

Nee, als het vergrendelingsniveau of isolatieniveau niet correct is gekozen, kan er een "lost update" optreden — wanneer wijzigingen van één transactie verloren gaan door een andere. Het is belangrijk om de mechanismen voor concurrentiebeheer zorgvuldig te kiezen.

Typische fouten en anti-patterns

Onjuiste keuze van isolatieniveau (te laag of te hoog)
Onvoldoende expliciete vergrendelingen in kritieke queries
Overmatig gebruik van globale (table-level) vergrendelingen, wat leidt tot prestatieverlies
Het niet vrijgeven van vergrendelingen door onafgemaakte transacties

Voorbeeld uit het leven

Negatieve case

In de analyseeenheid worden twee programma's tegelijkertijd gebruikt om de status van bestellingen bij te werken. Om te versnellen is opzettelijk het niveau READ UNCOMMITTED ingesteld om rijen niet te vergrendelen. Dit leidde tot conflicten en "verloren" updates, waardoor een deel van de gegevens beschadigd raakte.

Voordelen:

Goede snelheid in het begin

Nadelen:

Verlies/beschadiging van belangrijke gegevens
Moeilijkheden bij herstel

Positieve case

In de verkoopafdeling zijn kritieke gebieden gewikkeld in TRANSACTION + SELECT ... FOR UPDATE. Ze hebben lees- en updatebewerkingen op rijniveau gescheiden.