Nebenläufigkeit und Sperrverwaltung¶
Warum Sperren wichtig sind¶
Ohne Sperren können gleichzeitige Anfragen zu Race Conditions führen:
- doppelte offene Einladungen
- doppelte Akzeptanz-/Ablehnungsübergänge
- zwei Züge im gleichen Spielzug angewendet
Sperrmodell des Frameworks¶
Die Service-Schicht erwirbt Datenbanksperren, bevor sie Laufzeitmutationen delegiert:
- Sperren auf Paar-Ebene für Einladungs-Erstellung (gleiches Benutzerpaar)
- Sperren auf Spiel-Ebene für Akzeptieren/Ablehnen/Abbrechen/Verlieren/Zug
Operationen sind in DB-Transaktionen innerhalb servicebasierter Mutationsmethoden gekapselt.
Laufzeit-Regeln für Änderungen¶
- Gleichzeitige Anfragen werden angenommen
- Verlasse dich auf Muster: gesperrtes Lesen + Validieren + Schreiben
- Vertraue niemals veralteten Frontend-Zuständen
- Lies den persistierten Zustand innerhalb des Mutationspfads vor dem Schreiben erneut
Empfohlenes Mutationsmuster¶
- Akteur auflösen und validieren
- Gesperrte Spielzeile laden
- Statusübergang und Payload validieren
- Deterministischen nächsten Zustand berechnen
- Spielzeile aktualisieren
- Zugzeile anhängen (falls zutreffend)
- Normalisierte Payload zurückgeben
Richtlinien zur Idempotenz¶
Bevorzuge soft-idempotentes Verhalten bei Wiederholungen:
- Wiederholte gleiche Aktion auf bereits angewendetem Zustand kann aktuellen Payload zurückgeben
- Nicht autorisierte oder semantisch ungültige Aktionen sollten weiterhin Fehler auslösen