Diskussion:Verlorenes Update

Allgemeine Kritik

Hmm, in einer Enzyklopädie erwarte ich eigentlich einen gänzlich anderen Artikel als diesen hier, der im Wesentlichen eine Anleitung zum Vermeiden von Programmierfehlern sein will, die zu "Lost Updates" führen. Mal ein paar Kritikpunkte:

• ein Lost Update ist kein Fehler, sondern zunächst mal ein Phänomen.
• Was bitte soll das A: oder B: in der Überschrift?
• Furchtbarer Programmiererslang, Umgangssprache. Unnötig beispielhaft. SQL-Code -911? Was soll der Quatsch?
• Wo kommt die Frage/Überschrift nach Sperrmechanismen denn überhaupt her? Warum wird sie gestellt? Wird nicht motiviert.
• Isolationslevel RR: der sollte mindestens einmal ausgeschrieben werden
• Überhaupt nicht klar wird eigentlich, dass alle anderen isolationslevel das Problem noch nicht beheben
• Timouts beim Warten auf den Lock und Deadlocks sind wirklich völlig am Thema "Lost Update" vorbei, bereits woanders besser erklärt und haben hier einfach nichts zu suchen
• dass die serialisierung der verarbeitung eine folge der Locks ist - oder die Locks eben ein Hilfsmittel zur Serialisierung - dass das also keine unabhängigen paar schuhe sind - wird gar nicht erklärt
• der Abschnitt B führt dann als Lösung Optimistic Concurrency ein, verlinkt aber nicht drauf

-- (Anonym) 27.08.2009 (nicht signierter Beitrag von 192.109.111.157 (Diskussion | Beiträge) 19:46, 27. Aug. 2009 (CEST))

Abhilfe

Der Abschnitt "Abhilfe" ist im Prinzip eine Schlussfolgerung aus eigenen Überlegungen und Wikipediaartikeln zu verwandten Theman (insb. Isolation_(Datenbank)). In einer Vorlesung habe ich gehört, dass Lost Update auch durch das Isolationslevel 1 (read committed) verhindert werden kann, was mir allerdings unverständlich ist (und die entsprechenden Wikipediaartikel liefern dafür keine Erklärung). Ich hab deshalb die Markierung über den Abschnitt gestezt, weil ich nicht weiß ob er richtig/vollständig ist. Ich werde versuchen das nachzuprüfen, kann aber ein paar Tage dauern. Wenn jemand die Lösung weiß, nur zu :-) --Aardjon 14:35, 15. Feb. 2007 (CET)

Das kommt darauf an, wie die Anwendung gestaltet ist. In einigen Fällen mag das reichen, in anderen Fällen nicht. Ich habe vor, diesen Artikel zu überarbeiten - eigentlich neu zu gestalten. 20. Feb. 2007

So, das sollte schon mal einige Fragen beantworten. Der Teil B ist für die Praxis der wichtigere. Er kommt später. --82.135.37.138 18:12, 4. Apr. 2007 (CEST)

Parallele Programmierung

Verlorene Updates können auch bei Multi-Threading auftreten, daher wäre zumindest ein Verweis auf das Thema Mutexes wünschenswert. Vermutlich verwenden Datenbanken ja zumindest ähnliche Strukturen intern.

Einleitung

"Verlorenes Update [...] bezeichnet [...] einen Fehler, der bei mehreren parallelen Schreibzugriffen auf eine gemeinsam genutzte Information auftreten kann. Wenn zwei Transaktionen dieselbe Information verändern, dann können die Änderungen der ersten sofort durch die Änderungen der zweiten überschrieben werden."

Die Einleitung hat nichts mit dem Rest des Artikels zu tun. Sie beschreibt das "Problem" folgendermaßen: Es wird ein Schreibzugriff durchgeführt, wobei das Ergebnis hier verloren geht, da ein erneuter Schreibzugriff an dieser Stelle passiert. (Wo soll hier eigentlich das Problem sein??)

Beim Beispiel A geht es plötzlich um etwas komplett anderes, nämlich darum dass mit einer veralteten Kopie eines Wertes gerechnet wird, und das daraus resultierende falsche Ergebnis festgeschrieben wird. -- Metalbeppi 21:35, 26. Jan. 2010 (CET)

Isolationslevel CS

Im Abschnitt Der Isolationslevel RR steht in Klammern

(wie z.  B. bei Isolationlevel CS)

Also im Isolationslevel Artikel gibt es kein Level CS. Also, wovon spricht der Schreiber da? Sollte dieses Level CS dann nicht auch in den Isolationsartikel mit aufgenommen werden, sofern es denn existiert? --Ilker Savas (Diskussion) 23:01, 16. Mär. 2013 (CET)

Gemeint ist hier anscheinend Read Committed. Aus der Doku der DB2: "The keyword CS can be used as a synonym for READ COMMITTED" [1]. Ich selber habe CS in dem Zusammenhang auch noch nie gehört, kann sein, dass das nur im DB2-Umfeld so gehandhabt wird. Ich würde deshalb im Artikel eher Read Committed anstelle von CS schreiben. Tz92 (Diskussion) 10:23, 17. Mär. 2013 (CET)

Hi Tz92, ich habe deinen Link verfolgt und habe die Stelle gelesen, aber nicht weiterverfolgt, wie die von IBM in diesem Fall alternativ auf "CS" kommen. Da ich selber davon verwirrt werde und du auch und ich mir denken kann, dass das auch andere treffen wird werde ich diese Klammer mal mit nem entsprechenden Kommentar löschen, danke für die Recherche. --Ilker Savas (Diskussion) 23:08, 17. Mär. 2013 (CET)

Abstraktere Formulierung erforderlich

Ich schließe mich des meisten Äußerungen der Vorredner vollumfänglich an. Der ganze Artikel sollte aber wesentlich abstrakter formuliert werden und sich nicht nur auf RDBMS bzw. SQL beziehen, da ansonsten die viel weiter reichenden Auswirkungen des Lost-Update-Phänomens verlorengehen. Bereits beim Entwurf von Hardwarearchitekturen sind derartige Themen relevant. Selbstverständlich kommt es auch ohne den Einsatz von Computers potentiell zum Auftreten solcher Phänomene und der daraus resultierenden Probleme. Schweigstill (Diskussion) 20:02, 20. Jun. 2017 (CEST)