Hallo leute...
was ist eigentlich der genaue unterschied zwischen einem
nonrepeatable read und einem
phantom read???
danke,
marco
Vollständige Version anzeigen: nonreapeatable vs phantom read
beim non können sich die daten beim erneuten lesen ändern, beim phantom könnens nur mehr werden, dh die db kann grösser werden.
Zitat(cleanerjp @ 05 Feb 2007, 20:08)
beim non können sich die daten beim erneuten lesen ändern, beim phantom könnens nur mehr werden, dh die db kann grösser werden.
ah... cool... danke...
hi - ich hab von einem phantom read ne andere Auffassung.
Phantom read heißt, dass Datenbankeinträge - während deiner Transaktion veränderbar blieben. D.h. es können mehr oder weniger Datensätze sein bzw. sich die Attribute im resultset verändert haben. So, und das trifft nun mal für die drei Transaktionstypen für read uncommitted, read committed und repeatable read eben auch zu. Selbst bei repeatable read - weil n-Selects in einer Transaktion dort eben nur auf einen Stand vor der Transaktion ablaufen - und im Hintergrund - parallel - können sich darunter jedoch Änderungen ergeben haben! Nur bei serializeable werden die betroffenen Tables gesperrt! Damit ist ein phantom read ausgeschlossen.
Nun zum nonrepeatable read (2 selects in einer Transaktion - 2 unterschiedliche Ergebnisse)- der tritt deshalb nur beim read uncommitted und read committed auf, weil beide in einer Transaktion alles lesen, was gerade während ihrer Transaktionen verändert hat. Repeatable read jedoch liest nur das was vor seiner Transaktion bekannt war - so ne Art View - Kopie! Daher sind dort n-selects in einer Transaktion stimmig. Serializable sperrt die Tabellen und liest ebenso einen konstanten Datenbestand.
bye
Rheno
Phantom read heißt, dass Datenbankeinträge - während deiner Transaktion veränderbar blieben. D.h. es können mehr oder weniger Datensätze sein bzw. sich die Attribute im resultset verändert haben. So, und das trifft nun mal für die drei Transaktionstypen für read uncommitted, read committed und repeatable read eben auch zu. Selbst bei repeatable read - weil n-Selects in einer Transaktion dort eben nur auf einen Stand vor der Transaktion ablaufen - und im Hintergrund - parallel - können sich darunter jedoch Änderungen ergeben haben! Nur bei serializeable werden die betroffenen Tables gesperrt! Damit ist ein phantom read ausgeschlossen.
Nun zum nonrepeatable read (2 selects in einer Transaktion - 2 unterschiedliche Ergebnisse)- der tritt deshalb nur beim read uncommitted und read committed auf, weil beide in einer Transaktion alles lesen, was gerade während ihrer Transaktionen verändert hat. Repeatable read jedoch liest nur das was vor seiner Transaktion bekannt war - so ne Art View - Kopie! Daher sind dort n-selects in einer Transaktion stimmig. Serializable sperrt die Tabellen und liest ebenso einen konstanten Datenbestand.
bye
Rheno