Optimistic Locking

Jede Entity in Codemeta OS hat ein numerisches version-Feld. Es startet bei 1 und wird bei jedem erfolgreichen Update um eins erhöht. Sie nutzen es, um konkurrierende Schreibvorgänge zu erkennen.

So funktioniert’s

1. Sie lesen eine Entity per GET und merken sich die version.
2. Sie schicken einen PATCH und legen die gemerkte version ins Body-Objekt.
3. Wenn die Datenbank-Version noch übereinstimmt, geht das Update durch und version wird auf <n+1> gesetzt.
4. Wenn nicht, antwortet die API mit 409 Conflict und Sie wissen, dass ein anderer Schreiber Sie überholt hat.

Beispiel

# Schritt 1: aktuellen Stand lesen
curl https://os.codemeta.de/api/v1/tickets/<id> \
  -H "X-Tenant-Id: $TENANT" \
  -b cookies.txt
# → { "id":"…", "version": 7, "title":"…", … }

# Schritt 2: Update mit version
curl -X PATCH https://os.codemeta.de/api/v1/tickets/<id> \
  -H "X-Tenant-Id: $TENANT" \
  -H "Content-Type: application/json" \
  -b cookies.txt \
  -d '{"version": 7, "priority": "high"}'

Wenn die Server-Version inzwischen 8 ist, bekommen Sie:

{
  "type": "https://codemeta-os.de/probs/version-conflict",
  "title": "Version conflict",
  "status": 409,
  "detail": "The entity has been modified since you last read it.",
  "currentVersion": 8
}

Strategie für 409

• Erneut lesen. Holen Sie die aktuelle Entity, mergen Sie Ihre Änderung mit den neuen Feldern, schicken Sie das Update mit der neuen version ab.
• Nicht stumpf wiederholen. Ohne neues Lesen läuft Ihr Retry in dieselbe 409-Antwort.
• Bei UI-Workflows den Anwender fragen. Wenn die fremden Änderungen inhaltlich kollidieren, ist eine Auto-Merge-Strategie selten richtig.

Verwandte Konzepte

• Audit-Historie
• Entity-System
• Plattform-Garantien