0%

Hoofdstuk 7

Meerdere wijzigingen, één uitkomst

Wanneer een uitleen halverwege stopt

Een lid vraagt om het projectiescherm en de reparatieset samen te lenen. Als je dat verzoek als twee losse wijzigingen behandelt, kan er een resultaat overblijven waar niemand om heeft gevraagd.

Dit is het voorgestelde paar:

Uitleen-IDVoorwerp-IDLid-IDUitleendatum
70014172026-08-26
700259992026-08-26

De eerste rij is geldig. De tweede verwijst naar lid 999, dat niet bestaat. Stel dat een programma de eerste rij opslaat en afrondt voordat het de tweede probeert:

Proposed loans: [(7001, 4, 17, '2026-08-26'), (7002, 5, 999, '2026-08-26')]
Second loan: rejected by the missing-member rule
New loan IDs after reopening: [7001]
Wanted new loan IDs: []

De database heeft de ongeldige instructie terecht geweigerd. Ze wist niet dat de twee instructies één verzoek voorstelden. Uitlening 7001 blijft staan, dus de catalogus legt maar de helft van de gevraagde uitleen vast.

Voor deze bewerking betekent succes dat beide nieuwe rijen zijn opgeslagen. Mislukking betekent dat geen van beide nieuwe rijen is opgeslagen. Deze alles-of-nietseigenschap heet atomiciteit. Een database-transactie groepeert wijzigingen zodat ze samen één uitkomst bereiken.

Atomiciteit betekent niet dat elke twee instructies overal moeten worden gegroepeerd. Het volgt de betekenis van de bewerking. Twee onafhankelijke leden die losstaande voorwerpen lenen, kunnen aparte uitkomsten hebben. Deze twee rijen vormen één verzoek om een set, dus een opgeslagen eerste deel is geen bruikbaar succes.

Wat ging er mis bij de waargenomen uitleen van twee voorwerpen?

Python heeft een duidelijk succespunt en een duidelijk foutpad nodig. Begin met de succesvolle kant voordat je verandert hoe fouten worden afgehandeld.