50 Jahre später: Ist Two-Phase Locking das Beste, was wir tun können?

• Dieser Artikel diskutiert das Konzept des Two-Phase Locking (2PL), einer allgemeinen Form der Nebenläufigkeitskontrolle, die vor etwa 50 Jahren erfunden wurde.
• 2PL bietet mit Serializability und Opacity stärkere Isolationsniveaus und wird für Transaktionen über mehrere Datenelemente verwendet.
• Der Autor betont, dass die Einfachheit von 2PL und seine starken Isolationsniveaus die wichtigsten Vorteile sind.
• Allerdings hat 2PL Nachteile wie geringe Leseskalierbarkeit und Live-Lock-Fortschritt.
• Der Autor stellt mit Two-Phase Locking Starvation-Free (2PLSF) eine neue Nebenläufigkeitskontrolle vor, die die Probleme von 2PL behebt.
• 2PLSF verwendet bessere Reader-Writer-Locks und bietet starvation-freie Transaktionen, die höchste Form blockierenden Fortschritts.
• 2PLSF ist wirksam bei der Lösung bestimmter Arten von Konflikten und kann daher auch bei einigen auftretenden Konflikten skalieren.
• Der Autor kommt zu dem Schluss, dass 2PLSF gegenüber 2PL eine erhebliche Verbesserung darstellt, und vergleicht den Unterschied mit dem zwischen einem Presslufthammer und einer Spitzhacke.
• Der Artikel enthält Links zu einem Paper über den 2PLSF-Algorithmus sowie zum Source Code, die für weiterführendes Lernen herangezogen werden können.

[GN⁺]

Hacker-News-Kommentare

• Ein Artikel über Two-Phase Locking (2PL) und seine Relevanz 50 Jahre nach seiner ursprünglichen Entwicklung.
• Ein Kommentator erwähnt, dass er Anfänger bei diesem Thema ist, und sucht nach einer leicht einsetzbaren Konsistenzlösung für verteilte Microservices-Architekturen.
• Derselbe Kommentator teilt Python-Code zum Testen von Nichtdeterminismus in einer Multithreading-/Multiprocessing-Umgebung.
• Ein anderer Kommentator schlägt vor, zunächst zu prüfen, ob überhaupt ein Locking-Algorithmus nötig ist, und Anfragen zu bündeln, um Nebenläufigkeit und Sperren zu reduzieren.
• Es wird die Frage gestellt, wie sich der neue Ansatz mit Serializable Snapshot Isolation (SSI) vergleichen lässt, das als verbesserte Version von 2PL vermarktet wird.
• Ein Kommentator schlägt vor, dass Hacker News eine neue Richtlinie einführen sollte, nach der alle veröffentlichten Links HTTPS verwenden müssen.
• Es wird ein Link zu einer Arbeit des Autors über 2PLSF geteilt, von dem behauptet wird, dass es so sei, wie 2PL ursprünglich gedacht war.
• Es wird vorgeschlagen, eine zufällige Warteschlange hinzuzufügen, um die Skalierbarkeit atomarer Operationen zu verbessern.
• Es wird gefragt, ob es beim Wait-Or-Die-Ansatz notwendig ist, Transaktions-IDs zu beziehen und anzuhängen; stattdessen werden Thread-IDs oder Zufallszahlen vorgeschlagen.
• Ein Kommentator versteht die letzte Abbildung zu gelockerten AVL-Bäumen im Kontext schreibgeschützter Transaktionen nicht.
• Es wird die Frage gestellt, wie gut 2PL im Kontext lose gekoppelter API-Aufrufe anwendbar ist.
• Es wird darauf hingewiesen, dass die meisten Schreibtransaktionen konsistente Lesevorgänge für viele umkämpfte Objekte benötigen, die tatsächlichen Schreibvorgänge aber oft nur ein oder zwei Objekte betreffen; dazu wird gefragt, ob 2PL dieses Problem löst.