Warum MVCC für DML-Anweisungen Sperren erfordert

Question

In PostgreSQL, der MVCC concurrency control Mechanismus sagt, dass:

MVCC Schlösser zum Abfragen (Lesen) erfassten Daten nicht in Konflikt mit Sperren zum Schreiben von Daten erworben, und das Lesen so nie Blöcke und Schreiben nie blockiert Lesen

werden die aktuell betroffenen Zeilen, so dass keine andere Transaktion kann sie ändern, bis die aktuelle Transaktion festgeschrieben oder zurückgesetzt so even for READ_COMMITTED, eine Anweisung UPDATE Schreiben sperren.

Wenn eine gleichzeitige Transaktion ein UPDATE für die gesperrten Zeilen ausgibt, wird die zweite Transaktion blockiert, bis die erste ihre Sperren freigibt.

1. Ist dieses Verhalten trying to prevent the write-write conflicts?

2. Verlorene Aktualisierungen können weiterhin in READ_COMMITTED auftreten, da nach der ersten Transaktion die zweite Zeile überschrieben wird (auch wenn die Datenbank zwischen dem Start der UPDATE-Abfrage und dem Ende der Abfrage geändert wurde). Wenn also verlorene Updates noch möglich sind, warum muss die zweite Transaktion warten? Können die Snapshots auf Zeilenebene nicht zum Speichern der nicht festgeschriebenen Transaktionsänderungen verwendet werden, um zu vermeiden, dass Transaktionen auf die Freigabe von Schreibsperren warten müssen?

Answer 1

Die Antwort auf die erste Frage ist Ja. Kein DBMS kann schmutzige Schreibvorgänge unterstützen; Wenn zwei Transaktionen T1 und T2 gleichzeitig ausgeführt werden und T2 eine Aktualisierung von T1 überschreibt, kann das System den Fall nicht behandeln, in dem T1 anschließend ein ROLLBACK ausgibt, da die Aktualisierung von T2 bereits erfolgt ist.

Um unkorrekte Schreibvorgänge zu vermeiden, war die ursprüngliche Definition für die Snapshot-Isolation "First Committer Wins" - das heißt, widersprüchliche Schreibvorgänge wären zulässig, aber nur die erste Transaktion, die ein COMMIT ausgeben konnte - alle anderen Konflikte Transaktionen müssten ROLLBACK werden. Aber dieses Programmiermodell ist etwas problematisch, wenn nicht verschwenderisch, da eine Transaktion möglicherweise einen wesentlichen Teil der Datenbank aktualisiert, nur um am Ende die Möglichkeit zum COMMIT zu verweigern. Anstelle von "First Committer Wins" implementieren die meisten DBMS-Systeme, die MVCC unterstützen, "First Updater Wins", indem sie das traditionelle zweiphasige Locking verwenden.