Isolation levels

[mentor_]

Hi,

seit stunden versuche ich raus zu bekommen wie der 4. Isolation level
funktioniert. Also der Serializable Level. Die anderen habe ich verstanden.
Ich habe hierfür ein kleines und einfaches Beispiel erstellt:

Siehe hier: http://nopaste.php-quake.net/38396

Leider weiss icht nicht wie analog dazu der Serializable Level aussieht.
Wäre sehr dankbar, wenn mir jemand helfen könnte.

Leider finde ich im internet einfach keine beispiele. Es wird zwar immer mit Worten
erklärt, aber nur mittels der Beschreibung verstehe ichs nicht.

Danke,
Gruß Mentor

[dimitri]

Hi,

wenn deine Session serializable ist, dann siehst Du committete Änderungen aus anderen Sessions nicht bis Du einen COMMIT oder ROLLBACK ausführst.

Im Level Read Committet ist Datenkonsistenz auf Statementlevel vorhanden ist (ein SQL sieht immer den Datenstand zum Zeitpunkt des Abfragebeginns auch wenn sich die Daten zwischenzeitlich geändert haben).
Im Level Serializable ist das ganze auf Transaktionsebene realisiert. Wenn Deine Session zum Zeitpunkt T1 serializable wird, dann siehst Du bis zum Ende deiner Transaktion nur die Daten die zu T1 committet waren. Spätere Änderungen bekommst Du nicht mit.

In Oracle gibt es übrigends nur Read Committet und Serializable. Die anderen beiden sind nicht vorhanden bzw. auch nicht nötig.

Dim

[mentor_]

Hi,

danke für deine Antwort!

wenn deine Session serializable ist, dann siehst Du committete Änderungen aus anderen Sessions nicht bis Du einen COMMIT oder ROLLBACK ausführst.

Für mich ist das aber nicht serializable sondern Repeatable Read.
Ich sehe solange die die Änderungen der fremden Transaktion nicht, bis
ich ein Commit oder Rollback durchführe, erst dann beim naechsten select sehe ich die Änderungen des anderen Users. Genau so habe ich
in meinem Beispiel Repeatable Read umgesetzt.

AUch deine weiteren Erläuterungen deuten für mich eher auf ein Repeatable Read hin, als auf Serializable.

Könntest du die Unterschiede zwischen den beiden vielleicht nochmal kurz verdeutlichen. Eventuell anhand eines kleinen Beispieles so wie ich?
Danke

Gruß Mentor

[dimitri]

Da es in Oracle keinen Repeatable Read gibt, kann ich auch kein Beispiel anbringen ;-)

Im Gegensatz zu serializable ist im repeatable read ein Phantom Read möglich. Des weiteren blockieren sich Änderungen auf den gleichen Datensatz nicht.

Ändert also Session1 den Datensatz X und auch Session2, dann gibt es keinen Lock und beide können irgendwann committeten. Das hat zur Folge, dass Du ohne die Möglichkeit etwas dagegen zu tun die Änderungen eines anderen überschreibst. Das nennt man lost update.

In einer serializable Session wartest Du in diesem Fall. Macht die andere Session einen commit, bekommst Du einen Fehler und merkst somit, dass sich die Daten geändert haben und kannst entsprechend reagieren. Macht die andere Session hingegen einen Rollback, dann kann die wartende Session ihrerseits die Änderung machen.



In den meisten Anwendungsfällen reicht aber der read committet Level zusammen mit einer Application, die optimistisches Lockingverhalten implementiert.

Dim