Auf dieser Seite werden Transaktionsdatenkonflikte, Serialisierbarkeit und Isolation beschrieben. Beispiele für Transaktionscodes finden Sie stattdessen unter Transaktionen und Batch-Schreibvorgänge .
Transaktionen und Datenkonflikte
Damit eine Transaktion erfolgreich ist, müssen die durch ihre Lesevorgänge abgerufenen Dokumente durch Vorgänge außerhalb der Transaktion unverändert bleiben. Wenn ein anderer Vorgang versucht, eines dieser Dokumente zu ändern, gerät dieser Vorgang in einen Datenkonflikt mit der Transaktion.
- Datenkonflikt
- Wenn zwei oder mehr Vorgänge um die Kontrolle desselben Dokuments konkurrieren. Beispielsweise könnte eine Transaktion erfordern, dass ein Dokument konsistent bleibt, während ein gleichzeitiger Vorgang versucht, die Feldwerte dieses Dokuments zu aktualisieren.
Cloud Firestore löst Datenkonflikte, indem es einen der Vorgänge verzögert oder fehlschlägt. Die Cloud Firestore-Clientbibliotheken wiederholen automatisch Transaktionen, die aufgrund von Datenkonflikten fehlschlagen. Nach einer begrenzten Anzahl von Wiederholungsversuchen schlägt der Transaktionsvorgang fehl und es wird eine Fehlermeldung zurückgegeben:
ABORTED: Too much contention on these documents. Please try again.
Bei der Entscheidung, welcher Vorgang fehlschlagen oder verzögert werden soll, hängt das Verhalten vom Typ der Clientbibliothek ab.
Die Mobil-/Web-SDKs verwenden optimistische Parallelitätskontrollen.
Die Server-Client-Bibliotheken verwenden pessimistische Parallelitätskontrollen.
Datenkonflikt in den Mobil-/Web-SDKs
Die Mobil-/Web-SDKs (Apple-Plattformen, Android, Web, C++) verwenden optimistische Parallelitätskontrollen, um Datenkonflikte zu lösen.
- Optimistische Parallelitätskontrollen
- Basierend auf der Annahme, dass Datenkonflikte unwahrscheinlich sind oder dass es nicht effizient ist, Datenbanksperren aufrechtzuerhalten. Optimistische Transaktionen verwenden keine Datenbanksperren, um andere Vorgänge daran zu hindern, Daten zu ändern.
Mobile/Web-SDKs verwenden optimistische Parallelitätskontrollen, da sie in Umgebungen mit hoher Latenz und einer unzuverlässigen Netzwerkverbindung betrieben werden können. Das Sperren von Dokumenten in einer Umgebung mit hoher Latenz würde zu viele Datenkonfliktfehler verursachen.
In den Mobile/Web-SDKs verfolgt eine Transaktion alle Dokumente, die Sie innerhalb der Transaktion lesen. Die Transaktion schließt ihre Schreibvorgänge nur ab, wenn sich während der Ausführung der Transaktion keines dieser Dokumente geändert hat. Wenn sich ein Dokument geändert hat, versucht der Transaktionshandler die Transaktion erneut. Wenn die Transaktion nach einigen Wiederholungsversuchen kein sauberes Ergebnis erhält, schlägt die Transaktion aufgrund von Datenkonflikten fehl.
Datenkonflikt in den Server-Client-Bibliotheken
Die Server-Client-Bibliotheken (C#, Go, Java, Node.js, PHP, Python, Ruby) verwenden pessimistische Parallelitätskontrollen, um Datenkonflikte zu lösen.
- Pessimistische Parallelitätskontrollen
- Basierend auf der Annahme, dass ein Datenkonflikt wahrscheinlich ist. Pessimistische Transaktionen verwenden Datenbanksperren, um zu verhindern, dass andere Vorgänge Daten ändern.
Server-Client-Bibliotheken verwenden pessimistische Parallelitätskontrollen, da sie eine geringe Latenz und eine zuverlässige Verbindung zur Datenbank voraussetzen.
In den Server-Client-Bibliotheken sperren Transaktionen die von ihnen gelesenen Dokumente. Die Sperre einer Transaktion für ein Dokument verhindert, dass andere Transaktionen, Batch-Schreibvorgänge und nicht-transaktionale Schreibvorgänge dieses Dokument ändern. Eine Transaktion gibt ihre Dokumentsperren zum Zeitpunkt der Festschreibung frei. Außerdem werden die Sperren freigegeben, wenn eine Zeitüberschreitung auftritt oder aus irgendeinem Grund ein Fehler auftritt.
Wenn eine Transaktion ein Dokument sperrt, müssen andere Schreibvorgänge darauf warten, dass die Transaktion ihre Sperre aufhebt. Transaktionen erhalten ihre Sperren in chronologischer Reihenfolge.
Serialisierbare Isolation
Datenkonflikte zwischen Transaktionen stehen in engem Zusammenhang mit den Isolationsstufen der Datenbank. Die Isolationsstufe einer Datenbank beschreibt, wie gut das System Konflikte zwischen gleichzeitigen Vorgängen verarbeitet. Konflikte entstehen durch die folgenden Datenbankanforderungen:
- Transaktionen erfordern genaue, konsistente Daten.
- Um Ressourcen effizient zu nutzen, führen Datenbanken Vorgänge gleichzeitig aus.
In Systemen mit einer niedrigen Isolationsstufe könnte ein Lesevorgang innerhalb einer Transaktion ungenaue Daten aus nicht festgeschriebenen Änderungen in einem gleichzeitigen Vorgang lesen.
Serialisierbare Isolation definiert die höchste Isolationsstufe. Serialisierbare Isolierung bedeutet Folgendes:
- Sie können davon ausgehen, dass die Datenbank Transaktionen nacheinander ausführt.
- Transaktionen werden von nicht festgeschriebenen Änderungen in gleichzeitigen Vorgängen nicht beeinflusst.
Diese Garantie muss auch dann gelten, wenn die Datenbank mehrere Transaktionen parallel ausführt. Die Datenbank muss Parallelitätskontrollen implementieren, um Konflikte zu lösen, die diese Garantie verletzen würden.
Cloud Firestore garantiert eine serialisierbare Isolierung von Transaktionen. Transaktionen in Cloud Firestore werden nach der Commit-Zeit serialisiert und isoliert.
Serialisierbare Isolation nach Festschreibungszeit
Cloud Firestore weist jeder Transaktion eine Commit-Zeit zu, die einen einzelnen Zeitpunkt darstellt. Wenn Cloud Firestore die Änderungen einer Transaktion in der Datenbank festschreibt, können Sie davon ausgehen, dass alle Lese- und Schreibvorgänge innerhalb der Transaktion genau zum Zeitpunkt des Festschreibens erfolgen.
Die tatsächliche Ausführung einer Transaktion erfordert eine gewisse Zeitspanne. Die Ausführung einer Transaktion beginnt vor der Festschreibungszeit und die Ausführung mehrerer Vorgänge kann sich überschneiden. Cloud Firestore wahrt die serialisierbare Isolation und garantiert Folgendes:
- Cloud Firestore schreibt Transaktionen in der Reihenfolge ihrer Festschreibungszeit fest.
- Cloud Firestore isoliert Transaktionen von gleichzeitigen Vorgängen mit einer späteren Festschreibungszeit.
Bei Datenkonflikten zwischen gleichzeitigen Vorgängen verwendet Cloud Firestore optimistische und pessimistische Parallelitätskontrollen, um Konflikte zu lösen.
Isolation innerhalb einer Transaktion
Die Transaktionsisolation gilt auch für Schreibvorgänge innerhalb einer Transaktion. Bei Abfragen und Lesevorgängen innerhalb einer Transaktion werden die Ergebnisse früherer Schreibvorgänge innerhalb dieser Transaktion nicht angezeigt. Selbst wenn Sie ein Dokument innerhalb einer Transaktion ändern oder löschen, geben alle Dokumentlesevorgänge in dieser Transaktion die Version des Dokuments zum Zeitpunkt des Festschreibens zurück, bevor die Schreibvorgänge der Transaktion ausgeführt werden. Lesevorgänge geben nichts zurück, wenn das Dokument zu diesem Zeitpunkt nicht existierte.
Probleme mit Datenkonflikten
Weitere Informationen zu Datenkonflikten und deren Behebung finden Sie auf der Seite zur Fehlerbehebung .