Concurrency
- David Op de Beeck
Context
Optimistic locking wordt gebruikt om data-integriteit te waarborgen bij het bewerken van gedeelde resources in een multi-user omgeving. Het lost specifiek het probleem op van concurrerende updates aan dezelfde data, zonder gebruik te maken van exclusieve locks die vaak prestatieproblemen kunnen veroorzaken.
Voorbeeld scenario
Stel dat twee API-clients, A en B, hetzelfde vastgesteld feit willen aanpassen. Client A haalt het vastgesteld feit op en voegt locaties toe via het overeenkomstige POST-endpoint. Terwijl client A bezig is, haalt client B hetzelfde vastgesteld feit op en voegt rechtsbrononderdelen toe via het overeenkomstige POST-endpoint.
Wanneer client A de wijzigingen opslaat, wordt de achterliggende versie van het vastgesteld feit bijgewerkt. Dit proces is transparant voor afnemers van de API, omdat het versienummer niet naar buiten toe wordt blootgesteld.
Wanneer client B vervolgens probeert op te slaan, wordt de update geblokkeerd vanwege optimistic locking. Dit komt doordat de achterliggende versie van het vastgesteld feit inmiddels is gewijzigd door client A, waardoor de gegevens van client B verouderd zijn.
Client B moet in dit scenario de wijzigingen opnieuw aanbrengen voordat de update succesvol kan worden opgeslagen.
Toegepaste concepten
Optimistic locking is van toepassing op onderstaande concepten. Deze concepten komen overeen met de top-level resources /aansluiter/v1/{resource} in de OpenAPI-specificatie.
stukken
sanctiedossiers
vastgestelde-feiten
handhavingsbeslissingen
kennisgevingen
publieke-schades
…
Foutafhandeling
Automatisch
Het VHP zal een request automatisch één keer opnieuw proberen als deze faalt door optimistic locking. Deze automatische poging zorgt ervoor dat de meeste concurrentieconflicten worden opgelost, zodat API-clients hier niet expliciet rekening mee moeten houden.
Manueel
In het geval dat de automatische poging ook niet succesvol is, zal de API een 500-statuscode teruggeven. De aanbevelingen zoals beschreven op API Idempotentie zijn van toepassing, waarbij we aanraden om de request opnieuw te proberen.
Aanbevelingen voor concurrent aanroepen van dezelfde resource
Het wordt afgeraden om dezelfde resource gelijktijdig aan te roepen vanuit verschillende (a)synchrone processen. In het ideale geval worden requesten naar dezelfde resource sequentieel verwerkt. Er kan echter een pragmatische afweging gemaakt worden als de kans op gelijktijdige aanpassingen van dezelfde resource klein is. In dergelijke gevallen kan worden gesteund op de automatische afhandeling van conflicten door de API.
Het is belangrijk om te benadrukken dat een proces niet mag steunen op het steeds opnieuw proberen van requesten na een 500-statuscode om optimistic locking problemen op te lossen. Het herhaaldelijk opnieuw versturen van deze requesten is geen robuuste oplossing en kan leiden tot inefficiëntie en verhoogde belasting van de API.