1 / 5

Rücksetzen

Rücksetzen. Bisher betrachtetes Scheduling gewährleistet Isolation, d.h. Serialisierbarkeit, setzt jedoch voraus, dass Transaktionen abgebrochen und rückgesetzt werden können.

colby
Download Presentation

Rücksetzen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Rücksetzen • Bisher betrachtetes Scheduling gewährleistet Isolation, d.h. Serialisierbarkeit, setzt jedoch voraus, dass Transaktionen abgebrochen und rückgesetzt werden können. • Jetzt zu betrachten: Rücksetzmechanismen, die gewährleisten, dass nicht erfolgreiche Transaktionen keinerlei Effekte bewirken (Atomizität). • Mögliche Gründe für Transaktionsabbruch: • Selbstaufgabe (Ausführung von abort-Operation), • Systembedingter Abbruch (z.B. wegen Verklemmung, Ressourcenmangel, I/O-Fehler), • Systemzusammenbruch mit Verlust des Hauptspeicherinhalts.

  2. Rücksetzbarkeit von Schedules (1) • Rücksetzen einer Transaktion Ti kann andere Transaktion Tj beeinflussen, die bereits von Ti gelesen hat und deshalb nun ebenfalls rückgesetzt werden muss. • Zur Erinnerung: Konfliktserialisierbarer (fast serieller) Schedule S4: r2(B) r2(T) w2(T) w2(B) r1(B) r1(T) a2c1. • CP(S4): Nur T1! Da aber T1 Wert B (und T) von T2 gelesen hat (dirty read), kann Atomizität von T1 nur durch Rücksetzen von T1 erreicht werden. • Vorgang ist als kaskadierendes Rücksetzen bekannt — unerwünscht, da Arbeit von T1 verloren geht.

  3. Rücksetzbarkeit von Schedules (2) a3 • Betrachte konfliktserialisierbaren (fast seriellen) Schedule S10: r3(T) w3(T) r3(B) w3(B) r2(B) r2(T) w2(T) w2(B) c2c3. • Rücksetzen von T3 fatal, da wegen dirty read auch T2 rückzusetzen wäre, dies aber die Dauerhaftigkeit von T2 verletzen würde. • Folgerung: Für Zwecke der Rücksetzbarkeit muss Menge der zulässigen Schedules über Serialisierbarkeit hinaus eingeschränkt werden. • Zum Vergleich: Kaskadierendes Rücksetzen S10: r3(T) w3(T) r3(B) w3(B) r2(B) r2(T) w2(T) w2(B) c3c2. a3

  4. Rücksetzbarkeit von Schedules (3) • Definition: Sei S Schedule. • S heißt rücksetzbar (wiederanlaufbar), wenn für alle Transaktionen Ti, Tj mit i j gilt: wenn Tj irgendein Datenelement x von Ti liest und S den Aufruf cj enthält, dann enthält S auch ci, und ci erfolgt vor cj. • Svermeidetkaskadierendes Rücksetzen, wenn für alle Transaktionen Ti, Tj mit i j gilt: wenn Tj irgendein Datenelement x von Ti liest, dann erfolgt zwischen wi(x) und rj(x) ein Aufruf vonci. • Zur Erinnerung: S heißt rigoros, wenn für alle Transaktionen Ti, Tj in CP(S) mit i j gilt: wenn oi(x) vor oj(x) in S und oi(x) unverträglich mit oj(x), dann erfolgtci vor oj(x). • Rigorose Schedules vermeiden kaskadierendes Rücksetzen und sind konfliktserialisierbar. • S2PL löst Isolation und Atomizität.

  5. Transaktionszustände abge- schlossen wieder- holbar festschreiben beenden verdrängen potentiell aktiv blockiert inkarnieren abbrechen einbringen abbrechen abbrechen neustarten wieder- anlaufbar geschei- tert auf- gegeben undo undo

More Related