Diskussion:Commit-Protokoll

Ein-Phasen-Commit-Protokoll??

Ist das Ein-Phasen-Commit-Protokolle eigentlich nur von theoretischer Natur oder gibt es Einsatzmöglichkeiten? --Dunkeltron 15:24, 5. Sep 2005 (CEST)

Das Ein-Phasen-Commit ist meines Erachtens die normale Vorgehensweise einer nicht-verteilten Datenbank.--89.56.170.193 10:08, 1. Apr 2006 (CEST)

zu 1: Das Ein-Phasen-Protokoll, wie es in diesem Artikel erklärt wird, ist unsinnig. Es gibt aber ein sinnvolles Ein-Phasen Protokoll, bei dem die Teilnehmer an einer verteilten Transaktion dem Koordinator ihr Commit-Ergebnis bereits zusammen mit dem Operationsergebnis liefern. Damit entfällt am Transaktionsende die Abstimmungsphase. Vorteil: weniger Kommunikation. Nachteil: Teilnehmer sind länger "in doubt", damit steigt das Risiko einer Blockierung. zu 2: Das normale Vorgehen in einer nicht verteilten DB hat auch zwei Phasen: 1. Phase: Sichern der Wiederholbarkeit 2. Phase: Freigeben der Sperren Rick.

Wozu jetzt die dritte Phase?

Mir wird aus der Darstellung nicht klar, was die dritte Phase bringt (bzw. die zweite von dreien). Sie bringt Verzögerung, aber keine Zustandssicherheit. Ich dachte, die drei Phasen ermöglichen Fehlertoleranz gegenüber einem ausfallenden Koordiantor. Ich kann aber hieraus nicht erkennen, wie das gehen soll. Leider habe ich auch keine andere Quelle gefunden und hätte es doch so gern verstanden. --Dunkeltron 15:24, 5. Sep 2005 (CEST)

Koordinator?? Agent?

Selbst wenn die Begriffe in der Datenbankwelt so verwendet werden, halte ich eine einheitliche Bezeichnung für wichtig. Allerdings habe ich anhand einiger recht ordentlicher Bücher beide Begriffe Koordinator (Datenbanken) und Agent (Datenbanken) nur in anderen Zusammenhängen vorgefunden: Der Begriff Koordiantor wird vielmehr wie im weiteren Text des Artikels als den Commit koordinierender Prozess verwendet. Der Begriff Agent kommt in meinen Büchern nur auf Englisch vor. Ich werde mal eine entsprechenden Änderung vornehmen. --Dunkeltron 15:24, 5. Sep 2005 (CEST)

Der Artikel ist dringend überarbeitungsbedürfig - habe leider keine Zeit sonst würde ich es selbst machen. Nur soviel: die Beschreibung zu 3PC ist unsinnig. 3PC hängt von einem Verfahrensparameter k ab, der hier gar nicht erwähnt wurde. 3PC gewährleistet, dass Blockierungen ("in doubt transaktioonen") vermieden werden sofern weniger als k Rechner ausfallen. Ist der Koordinator ausgefallen, so kann bei 3PC ein neuer Koordinator gewählt werden, der das Protokoll fortführt. Rick.

Man muss auch die Fehlerbedingungen betrachten. Sicheres Netz... nur Ausfälle von Knoten etc. Nille

2PC ist auch bei Netzwerkpartitionierungen korrekt! Das Problem ist die Blockierung des Algorithmus wenn der Koordinator ausfällt. 3PC verhindert die Blockierung. Es gibt eine Reihe von Varianten dieses Protokolls. Was im Artikel über Paxos steht ist falsch, oder zumindest irreführend. Zu behaupten bei 3PC riskiere man grundsätzlich inkonsistente Entscheidungen in verschiedenen Partitionen ist falsch. Paxos ist ein allgemeiner Consensus-Algorithmus der zunächst nichts mit commit zu tun hat. Es gibt aber auch den Paxos-Commit Algorithmus, der gegenüber dem 3PC eine Nachrichtenrunde einspart dafür aber bestimmte Annahmen bezüglich der Nachrichtenlaufzteit machen muss. (vgl.: ftp://ftp.research.microsoft.com/pub/tr/TR-2003-96.pdf). Ich würde den Passus über Paxos hier ganz rausnehmen. JohnTB 11:20, 4. Jul. 2008 (CEST)

Varianten/Zwei-Phasen-Commit-Protokolle/Algorithmus

In der Darstellung des Algorithmus heißt es: Dabei schreiben sie Einträge in ihr undo log und in ihr redo log. Im folgendem Text taucht das redo log nirgends wieder auf und es wird auch nicht erklärt wozu es gut ist beziehungsweise was es überhaupt ist. --Ceving (Diskussion) 13:43, 25. Sep. 2013 (CEST)