Verlorene Aktualisierungen verhindern

Wir beginnen mit dem optimistischen Sperrkonzept, das auf ETags (Entitäts-Tags) basiert. Um ETags für eine Modellentität zu aktivieren, fügen Sie die Annotation @odata.etag zu einem Element der Entitätsdefinition hinzu.

Im gezeigten Beispiel wird das modifiedAt-Element aus dem verwalteten Aspekt als ETag-Element sowohl für die Dokumentenmappenentität als auch für die Autorenentität definiert. Hierfür wird die annotate -Direktive verwendet, mit der vorhandene Definitionen annotiert werden können.

Die Idee eines ETags besteht darin, eine bestimmte Version einer Entität zu identifizieren, in unserem Beispiel die Version eines Buchs oder eines Autors. Damit kann die Integrität der Daten, wie im folgenden Beispiel erläutert, ohne Verwendung von Sperren gewährleistet werden.

Angenommen, wir rufen einen bestimmten Autor über die folgende Anfrage ab, da wir seine Daten ändern möchten:

1
GET Authors(18f76942-bfb3-40c5-8300-f999f14e9cc2)

Mit dieser Anfrage wird die Version des Autors, d.h. der Wert des ETag-Elements modifiedAt, automatisch über den HTTP-Response-Header ETag zurückgegeben, z.B.:

1
ETag: W/"2024-03-15T11:30:48.069Z"

Um Daten, die am Autor geändert wurden, zurückzuschreiben, wird der empfangene ETag-Wert wie folgt im HTTP-Header If-Match des entsprechenden Änderungsantrags verwendet:

1234567
PUT Authors(18f76942-bfb3-40c5-8300-f999f14e9cc2)
If-Match: W/"2024-03-15T11:30:48.069Z"
Content-Type: application/json

{ 
 ...
}

CAP prüft dann, ob sich der Inhalt des modifiedAt -Elements in der Zwischenzeit geändert hat. Ist dies nicht der Fall, werden die Autorendaten in der Datenbank geändert, und das Feld modifiedAt ETag wird aktualisiert. Wenn ja, bedeutet dies, dass der Autor seit dem Lesen der Daten über einen anderen Request geändert wurde. CAP bricht daher den Änderungsantrag ab und setzt den Statuscode 412 (Vorbedingung fehlgeschlagen) für die HTTP-Response. Der Antworttext enthält einen Fehler ähnlich dem folgenden:

12345
"error": {
  "code": "412",
  "message": "Precondition Failed",
  "@Common.numericSeverity": 4
}

Die optimistische Sperre stellt die Datenintegrität bei gleichzeitigen Änderungen durch verschiedene Anforderungen sicher.

Pessimistische Sperren hingegen gewährleisten die Datenintegrität bei gleichzeitigen Modifikationen durch gleichzeitige Transaktionen. Mit dem pessimistischen Sperren können Sie Daten sperren, sodass andere Transaktionen gegen Änderungen der Daten gesperrt sind.

CAP nutzt Datenbanksperren für pessimistische Sperren, wobei zwischen Schreibsperren und Lesesperren unterschieden wird.

Ausschließlich gesperrte Datensätze können von anderen Transaktionen weder geändert noch gelesen werden. Schreibsperren werden gesetzt, wenn die Datensätze von der Datenbank gelesen werden. Die Query API der CAP stellt dafür die Methode forUpdate() zur Verfügung.

Lesesperren verhindern auch gleichzeitige Aktualisierungen durch parallele Transaktionen. Sie erlauben jedoch allen Transaktionen, die gesperrten Datensätze zu lesen.

Um Lesesperren zu setzen, stellt das Abfrage-API die Methode forShareLock() bereit.

Erworbene Sperren (ob exklusiv oder gemeinsam) werden freigegeben, wenn die aktuelle Transaktion abgeschlossen, d.h. festgeschrieben oder zurückgesetzt wird.

Sehen Sie sich das Video an, um zu erfahren, wie Sie eine optimistische Parallelitätskontrolle hinzufügen.