Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

18
Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe

Transcript of Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Page 1: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen

Betriebliche Informationssysteme

Prof. Dr. Michael Löwe

Page 2: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 2

Inhalt

Begriffsbestimmung

ACID-Eigenschaft

Transaktionen auf 3 EbenenKlassische Transaktionen

Lange Transaktionen

Ganz lange Transaktionen

Resümee

Page 3: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 3

Begriffsbestimmung

Transaktion = „großes Geld- oder Bankgeschäft“Geldbewegungen auf „vielen“ Konten

„Alle“ Konten vom Anfangs- zum Endzustand

Transaktion als Einheit (Sicht von außen)Anfangszustand aller Konten Endzustand aller Konten

Transaktion als Struktur (Sicht von innen)Reihe von Geldbewegungen auf den Einzelkonten

Page 4: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 4

Begriffsbestimmung

Transition

ZustandAnfangszustand Endzustand

Schritt 1Schritt 1 Schritt 2Schritt 2 Schritt nSchritt n AbschlussAbschluss

BestätigenVerwerfen

DefinierterAnfang Arbeitsschritte

Transaktion

Page 5: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 5

Beispiele

Textverarbeitung zwischen zwei Speichervorgängen

Löschen einer Datei

Laden einer HTML-Seite

Erstellen und Versenden einer E-Mail

Erstellung einer Rechnung/Lieferscheins/etc.

Aktivitäten in einem Workflow

Umstellung auf vierstellige Jahreszahlen

Einführung des Euro

Page 6: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 6

ACID-Eigenschaften

A = Atomicity(2)

ganz = bestätigen = commit odergar nicht = verwerfen = roll back

C = Consistence(4)

Legale Zustände werden in legale Zustände überführt

I = Isolation(3)

Zwischenergebnisse sind außerhalb nicht sichtbar

D = Durability(1)

Die Ergebnisse (Zustandsänderungen) sind dauerhaft

(DAIC)

Page 7: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 7

Durability

(Fast) alle Daten sind dauerhaft gespeichertDatenbank,

File,

CD-ROM, DVD ...

Explizites Holen der Daten zur VerarbeitungOperation „Lesen“ oder „Read“

Explizites Speichern der Daten nach der VerarbeitungOperation „Schreiben“ oder „Write“

Page 8: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 8

AtomicityT: 100 DM von K1 auf K2T: 100 DM von K1 auf K2

200100

100

500

600600

1. K1 lesen (200)2. K1 schreiben (100)3. K2 lesen (500)4. K2 schreiben (600)5. Commit

K1 K2 Bestätigung

200100

200

500

600500

1. K1 lesen (200)2. K1 schreiben (100)3. K2 lesen (500)4. K2 schreiben (600)5. Roll Back

Abbruch

200100

200

500

ERR500

1. K1 lesen (200)2. K1 schreiben (100)3. K2 lesen (500)4. K2 schreiben (600)5. Auto Roll Back

K1 K2 Erkannter Fehler

200100

200

500

500

1. K1 lesen (200)2. K1 schreiben (100)3. K2 lesen (500)4. System(teil)absturz5. Auto Roll Back

Systemausfall

Page 9: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 9

Atomicity (Lost Update)T1: 100 DM von K1 auf K2T1: 100 DM von K1 auf K2 T2: 50 DM von K3 auf K2T2: 50 DM von K3 auf K2

1. K1 lesen (200)2. K1 schreiben (100)3. K2 lesen (500)

4. K2 schreiben (600)

5. Commit

1. K3 lesen (300)2. K3 schreiben (250)3. K2 lesen (500)

4. K2 schreiben (550)5. Commit

200100

500

600550

300

250

K1 K2 K3

Page 10: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 10

Isolation (Dirty Read)T1: 100 DM von K1 auf K2T1: 100 DM von K1 auf K2 T2: 50 DM von K3 auf K2T2: 50 DM von K3 auf K2

1. K1 lesen (200)2. K1 schreiben (100)

3. K2 lesen (500)4. K2 schreiben (600)

5. Roll back

1. K3 lesen (300)2. K3 schreiben (250)

3. K2 lesen (600)

4. K2 schreiben (650)5. Commit

200100

200

500

600

500650

300

250

K1 K2 K3

Page 11: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 11

Isolation (Unrepeatable Read)T1: K2 + K3 zu K1T1: K2 + K3 zu K1 T2: 50 DM von K3 auf K2T2: 50 DM von K3 auf K2

1. K1 lesen (200)2. K2 lesen (500)

3. K3 lesen (250)4. K1 schreiben (950)5. Commit

1. K3 lesen (300)2. K3 schreiben (250)3. K2 lesen (500)4. K2 schreiben (550)5. Commit

200

950

500

550

300

250

K1 K2 K3

Page 12: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 12

Consistence

Transition

Zustand

Schritt 1Schritt 1 Schritt 2Schritt 2 Schritt nSchritt n AbschlussAbschluss

DefinierterAnfang Arbeitsschritte

(1) Bestätigung versuchen

(3a) Bestätigen(3b) Verwerfen

(2) Check Constraints (a) o. k. (b) nicht o. k.

Transaktion

Summe allerKonten ist 0

Page 13: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 13

Transaktionen auf 3 Ebenen

Workflow Ganz lange Transaktion (> ein paar Tage)

Transaktion = Prozess/WorkflowArbeitsschritt = Aktivität

Aktivität Lange Transaktion (< ein paar Tage)

Transaktion = AktivitätArbeitsschritt = Geschäftsfunktion

Geschäftsfunktion Transaktion (< 3 Sekunden)

Transaktion = GeschäftsfunktionArbeitsschritt = Jede Aktualisierung der Speichermedien

Page 14: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 14

Ganz lange Transaktion (Workflow)Ganz lange Transaktion (Workflow)

Lange Transaktion(Aktivität)

Lange Transaktion(Aktivität)

Lange Transaktion(Aktivität)

Lange Transaktion(Aktivität)

Lange Transaktion(Aktivität)

Lange Transaktion(Aktivität)

Beginn Abschluss

Transaktionen auf 3 Ebenen

Commit, Roll Back

Transaktion(Funktion)

Transaktion(Funktion)

Transaktion(Funktion)

Transaktion(Funktion)

Transaktion(Funktion)

Transaktion(Funktion)

Commit, Roll Back

DB-UpdateDB-Update DB-UpdateDB-Update DB-UpdateDB-Update

Commit, Roll Back

Page 15: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 15

(Datenbank- bzw. TM-)Transaktion

Begin Work, Commit und Roll Back des DBMS

Transaktion ist DBMS-Objekt

Dauer < 3 Sekunden (Präsuppositionen des DBMS)

Vollautoamtisch; keine Unterbrechung durch Dialog

Durability durch DBMS

Atomicity durch Serialisierung der Transaktionen

Automatisches Roll Back bei Absturz

Isolation durch DBMS-Sperrmechanismen

Consistence durch DBMS-Mittel

Page 16: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 16

Lange Transaktionen

Begin Work, Commit und Roll Back als Transaktionen

Transaktion ist Systemobjekt

Dauer: bis zu mehreren Tagen

Ständige Unterbrechung durch Benutzerdialoge

Durability durch Durability der Geschäftsfunktionen

Atomicity „handgemacht“

Absturz kein Problem

Isolation durch Logische Sperren

Consistence durch Consistence der Geschäftsfunktionen

Page 17: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 17

Ganz lange Transaktionen

Begin Work, Commit, Roll Back kaum als Transaktionen

Transaktion ist das Workflow-Objekt

Dauer: mehrere Tage oder Wochen

Ständige Unterbrechung durch Akteur-Wechsel

Durability durch Durability der Geschäftsfunktionen

Atomicity „handgemacht“

Absturzprobleme, wenn Commit und Roll Back keine Transakt.

Isolation: ganz schwierig durch ganz lange Sperren

Consistence durch Consistence der Geschäftsfunktionen

Page 18: Transaktionen Betriebliche Informationssysteme Prof. Dr. Michael Löwe.

Transaktionen 18

Resümee

Transaktion ist das Konzept von GeschäftsanwendungenACID garantiert:

Bestand der Ergebnisse von Handlungen der AnwenderFertigwerden mit (Teil-)Systemausfällen und BenutzerabbruchSynchronisation im MehrbenutzerbetriebConsistence des Datenmodells

Die drei TransaktionsebenenWorkflow: kaum vorhanden, schwer zu realisierenAktivität: kaum vorhanden, Realisierung nötigGeschäftsfunktion: überall vorhanden, Realisierung durch

DBMS oder TP, schwierig in verteilten Systemen