Dies ist eine neue Frage auf DocumentDB. Wir möchten DocumentDB für unsere Anwendung verwenden. Wir haben mehrere Benutzer, die Daten ändern, die in einer DocumentDB gespeichert sind. Wie können wir sicherstellen, dass ein Benutzer die Änderungen eines anderen Benutzers nicht überschreibt?Nebenläufigkeit auf DocumentDB
DocumentDB schützt nicht vor Nebenläufigkeit. Wenn Sie eine neue Version des Dokuments über ein vorhandenes Dokument hochladen, wird das alte Dokument überschrieben. Wenn Sie gegen gleichzeitige Schreibvorgänge schützen können, müssen Sie den Zeitstempel des Dokuments verwenden. Jedes Dokument in DocumentDB hat einen Zeitstempel der letzten Aktion.
Bei jedem Update können Sie überprüfen, ob der Zeitstempel des Dokuments, das Sie aktualisieren möchten, dem von Ihnen abgerufenen entspricht oder sich geändert hat. Wenn sich geändert hat, hat der Benutzer nicht die neueste Version und Sie können das Update abbrechen.
Das beste Ding ist, eine gespeicherte Prozedur zu verursachen, also können Sie diese Logik in einen gespeicherten proc setzen und Ihre Anwendung unabhängig davon machen.
DocumentDB hat optimistischen Nebenläufigkeit und hat ein ETag auf jedem Dokument. Wenn sich der ETag beim Schreiben geändert hat, schlägt der Schreibvorgang fehl (wenn ETag geändert wurde, dh jemand anders das Dokument geändert hat). In diesem Fall müssen Sie das betreffende Dokument erneut lesen und erneut bearbeiten.
Siehe die FAQ here für weitere Informationen.
Insbesondere können Sie die Anforderungsoptionen und die Eigenschaft accessCondition verwenden, um die Etag- und IfMatch-Bedingung bereitzustellen. – njappboy
https://peter.intheazuresky.com/2016/04/28/documentdb-revisited-part-3-concurrency-in-documentdb/ hat mehr Details zur Verwendung von ETag. – njappboy
Es gibt einen eingebauten ETag-Mechanismus, der speziell damit umgeht. Das Überprüfen des Zeitstempels verhindert nicht, dass der Server Schreibvorgänge auf der Grundlage von ETag zurückweist (zwei Schreiber können gleichzeitig nach dem Zeitstempel suchen). –
Davids ist wirklich die bessere Antwort hier. "Optimistische Parallelität", "ETag", das sind die richtigen Begriffe. Es ist nicht offensichtlich, dass der ETag ein Zeitstempel ist. Außerdem würde ich nicht sagen, dass Sprocs für diese einfache Situation von Schreibvorgängen, die von zwei Benutzern kommen, am besten sind. Der ETAG-Mechanismus ist einfacher und leichter mit der Fehlerbehandlung zu handhaben als Sprocs. Sprocs _might_ ist am besten, wenn Sie in derselben Transaktion lesen und schreiben oder wenn Sie mehrere Schreibvorgänge ausführen, die konsistent sein müssen. Ich bevorzuge auch Sprocs für Schreibvorgänge zur Datenvalidierung. –