Diskussion:Isolation (Datenbank)
Bitte ändern: Das Phtanom Read bezieht sich nur wenn Folgendes auftritt: Eine Transaktion fragt eine Tabelle mithilfe einer where-Klausel ab, und eine zweite Transaktion fügt einen neuen Datensatz in die Tabelle ein. Dieser entspricht der where-Klausel, und daher ist eine zusätzliche Zeile mit Daten vorhanden, wenn die erste Transaktion die Tabelle unter Verwendung derselben where-Klausel anfordert. --TheMentor 13:14, 13. Okt. 2007 (CEST)
Die Tabelle zur Übersicht über die Probleme, die in den verschiedenen Isolationslevels auftreten können, scheint fehlerhaft zu sein. Die letzte Spalte ("Phantom Read") sollte vermutlich "Lost Update" heißen, da dies der eigentliche Unterschied zwischen Serializable und Repeatable-Read ist. Schließlich ist ein Phantom-Read nur ein Spezialfall eines Non-Repeatable-Reads und sollte somit im Isolationslevel Repeatable-Read nicht mehr möglich sein. -- Silverchecker301 21:40, 20. Aug. 2010 (CEST)
Fehlerhafte Tabelle und Informationen. Lost Update wird bei jedem Isolationslevel verhindert, weitere Fehler wurden korrigiert. -- Locked inside an empty room! 08:58, 1. Feb. 2011 (CET)
Dann erklaere doch mal bitte wie Lost Updates verhindert werden bei bei RU und RC. --84.238.21.110 13:40, 29. Mai 2011 (CEST)
Tabelle jetzt falsch!
[Quelltext bearbeiten]Jetzt ist die Tabelle falsch! Phantom Reads sind bei Repeatable Read möglich: http://download.oracle.com/javase/1.4.2/docs/api/java/sql/Connection.html siehe auch englische Version http://en.wikipedia.org/wiki/Isolation_%28database_systems%29
Evtl. könnte noch der Hinweis dazu, dass Serializable bei der DB2 Repeatable-Read heißt und Repeatable Read heißt bei DB2 Cursor Stability. (nicht signierter Beitrag von 145.253.187.66 (Diskussion) 09:27, 18. Feb. 2011 (CET))
Lost Update ist nicht bei allen unmöglich
[Quelltext bearbeiten]Laut meinen Recherchen ist das Lost Update Problem erst ab dem Isolationslevel Repeatable Read unterbunden. --ZerNot 19:28, 11. Mai 2011 (CEST)
Ja, so sehe ich das auch. Mindestens bei Read Uncommitted kann es zu Lost Update Problemen kommen. Gerade selber ausprobiert. --84.238.21.110 13:31, 29. Mai 2011 (CEST)
Ich wüsste mal gerne was ihr da ausprobiert habt. Lost Update ist immer unmöglich wenn Schreibsperren gemäß 2PL bis zum Commit gehalten werden. (vgl. z.B. http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Fdb2%2Frbafzmstisol.htm). Das ist z.B. bei DB2 bei allen Isolation Levels ausser NO-COMMIT der Fall. JohnTB (Diskussion) 10:36, 12. Jun. 2012 (CEST) Ich ziehe alles zurück. Tatsächlich ist die Doku von DB2 falsch und sogar die Angaben in Gray Reuter stimmen nicht. Beispiele werden in "Transactional Information Systems" Weikum Vossen gegeben. S 361. JohnTB (Diskussion)
Read Uncommitted bedeutet nicht: schutzlos. Laut SQL-Norm sind Dirty Writes (Lost Updates) grundsätzlich verboten, also auch im Eingangslevel Read Uncommitted. Eine Datenbank schützt seine Daten daher schon im Level Read Uncommitted mit einem Schreiblock! Ich zitiere ISO_9075_01_Framework_2011_E.pdf auf Seite 27 unten: "Every isolation level guarantees that no update is lost." (nicht signierter Beitrag von Edwin Schicker (Diskussion | Beiträge) 10:45, 10. Jul 2014 (CEST))
Beim Datenbankmanagmentsystem DB2 ist beim Isolation Level CS der Lost Update möglich. Isolation Level CS bei DB2 bedeutet READ COMMITTED. Nur wenn jede Transaktion entweder beim Lesen sperrt oder beim Schreiben prüft, ist der Lost Update nicht möglich! Beachten Sie bitte auch, dass der Isolation Level SERIALIZABLE von Oracle nicht die vom SQL Standard geforderte Eigenschaft hat. Jürgen Mangold