8. Transaktionsverwaltung Der Scheduler

8. Transaktionsverwaltung
■
■
■
■
■
Architektur der Transaktionsverwaltung
Sperrende und nicht-sperrende Verfahren
Transaktionen in SQL-Systemen
Transaktionsmonitore
Verteilte Transaktionen
VL Datenbank-Implementierungstechniken – 8–1
Der Scheduler
T1
T2
Tn
TransaktionsManager (TM)
Scheduler (SC)
korrekter Schedule
(bestehend aus r, w, c, a)
Speicher
Manager (SM)
Recovery
Manager (RM)
Puffer
Manager (PM)
DB
VL Datenbank-Implementierungstechniken – 8–2
Transaktionsoperationen
Transaktionsklammern
■ BOT (Begin of Transaction)
■ EOT (End of Transaction)
Schritte:
■ r (read),
■ w (write),
■ a (abort), und
■ c (commit).
t = {r|w}∗ (a|c)
VL Datenbank-Implementierungstechniken – 8–3
Zustände einer Transaktion
active
execute
delay
BOT
initial
running
delayed
restart
retry
reject
stop
aborted
EOT
committed
stopped
VL Datenbank-Implementierungstechniken – 8–4
Behandlung eines Schritts
ausführen (execute)
Transaktion → Zustand running.
■ verzögern (delay)
Transaktion → Zustand delayed
■ zurückweisen (reject)
Transaktion → Zustand aborted
■
VL Datenbank-Implementierungstechniken – 8–5
Aggressive Scheduler
ein Scheduler ist aggressiv, wenn er Konflikte zuläßt und
dann versucht, aufgetretene Konflikte zu erkennen und
aufzulösen
■ maximiert die Parallelität von Transaktionen
■ Risiko: Transaktionen werden erst am Ende ihrer
Ausführung zurückgesetzt
■
VL Datenbank-Implementierungstechniken – 8–6
Konservative Scheduler
ein Scheduler arbeitet konservativ, wenn er Konflikte
möglichst vermeidet, dafür aber Verzögerungen von
Transaktionen in Kauf nimmt
■ erlauben nur eine geringe Parallelität von Transaktionen
■ minimieren den Rücksetzungsaufwand für
abgebrochene Transaktionen
■ im Extremfall findet keine Parallelisierung von
Transaktionen mehr statt, d.h., es werden immer alle
Transaktionen bis auf eine verzögert
■
VL Datenbank-Implementierungstechniken – 8–7
Sperrmodelle
Schreib- und Lesesperren in folgender Notation:
■ rl(x): Lesesperre (engl. read lock) auf einem Objekt x
■ wl(x): Schreibsperre (engl. write lock) auf einem Objekt
x
Entsperren ru(x) und wu(x), oft zusammengefaßt u(x) für
engl. unlock
VL Datenbank-Implementierungstechniken – 8–8
Sperrdisziplin
■
■
■
■
■
■
Schreibzugriff w(x) nur nach Setzen einer Schreibsperre
wl(x) möglich
Lesezugriffe r(x) nur nach d rl(x) oder wl(x) erlaubt
nur Objekte sperren, die nicht bereits von einer anderen
Transaktion gesperrt
nach rl(x) nur noch wl(x) erlaubt, danach auf x keine
Sperre mehr; Sperren derselben Art werden maximal
einmal gesetzt
nach u(x) durch ti darf ti kein erneutes rl(x) oder wl(x)
ausführen
vor einem commit müssen alle Sperren aufgehoben
werden
VL Datenbank-Implementierungstechniken – 8–9
Verklemmungen
t1
wl(x)
t2
wl(y)
delay → wl(y)
wl(x)
← delay
Verklemmung!
Alternativen:
■ Verklemmungen werden erkannt und beseitigt
■ Verklemmungen werden von vornherein vermieden
VL Datenbank-Implementierungstechniken – 8–10
Verklemmungserkennung und -auflösung
Wartegraph
6
5
4
neue
Sperre
1
2
3
Auflösen durch Abbruch einer Transaktion, Kriterien:
■ Anzahl der aufgebrochenen Zyklen,
■ Länge einer Transaktion,
■ Rücksetzaufwand einer Transaktion,
■ Wichtigkeit einer Transaktion, ...
VL Datenbank-Implementierungstechniken – 8–11
Livelock-Problem
1.
2.
3.
4.
5.
6.
7.
8.
9.
T1
T2
T3
T1
T3
T2
T4
T3
T4
sperrt A
will A sperren, muß aber warten
will danach A sperren, muß auch warten
gibt A frei
kommt vor T2 an eine Zeitscheibe, sperrt A
will weiterhin A sperren, muß aber warten
will danach A sperren, muß auch warten
gibt A frei
kommt vor T2 an die nächste Zeitscheibe ...
VL Datenbank-Implementierungstechniken – 8–12
Sperrprotokolle: Notwendigkeit
T1
T2
wl(x)
w(x)
u(x)
wl(x)
w(x)
u(x)
wl(y)
w(y)
u(y)
wl(y)
w(y)
u(y)
VL Datenbank-Implementierungstechniken – 8–13
#Sperren
Zwei-Phasen-Sperr-Protokoll
2PL
AnforderungsPhase
FreigabePhase
Zeit
VL Datenbank-Implementierungstechniken – 8–14
Konflikt bei Nichteinhaltung des 2PL
T1
T2
u(x)
wl(x)
wl(y)
..
.
u(x)
u(y)
wl(y)
..
.
VL Datenbank-Implementierungstechniken – 8–15
#Sperren
Striktes Zwei-Phasen-Sperr-Protokoll
S2PL
AnforderungsPhase
Zeit
Freigabe-Phase
vermeidet kaskadierende Abbrüche!
VL Datenbank-Implementierungstechniken – 8–16
#Sperren
#Sperren
Konservatives 2PL-Protokoll
C2PL
CS2PL
FreigabePhase
Zeit
Zeit
AnforderungsPhase
AnforderungsPhase
FreigabePhase
vermeidet Deadlocks!
VL Datenbank-Implementierungstechniken – 8–17
Sperrgranulate
■
Granularitätshierarchien in Datenbanken
■
Hierarchische Sperren
■
Baumprotokolle für Baumindexe
VL Datenbank-Implementierungstechniken – 8–18
Granularitätshierarchien in RDBS
Granularitätshierarchien
Datenbank
Datenbank
Relation
Datei
Tupel
Cluster
Attribut
Seite
Logisch
Physisch
VL Datenbank-Implementierungstechniken – 8–19
Hierarchische Sperren
■
Sperren pflanzen sich nach unten (in Richtung der
Blätter) fort
■
Sperren dürfen nicht von oben (von der Wurzel her)
überschrieben werden
■
Zusätzlich: intentionale Sperren (engl. intentional locks)
Warnungen vor Sperren, die sich in der Hierarchie weiter
unten befinden
irl (intentionale Lesesperre) und iwl (intentionale
Schreibsperre)
VL Datenbank-Implementierungstechniken – 8–20
Kompatibilitätsmatrix
■
für elementare Sperren
rlj (x)
wlj (x)
rli (x) wli (x)
√
—
—
—
VL Datenbank-Implementierungstechniken – 8–21
Kompatibilitätsmatrix
■
für hierarchische Sperren
rlj (x)
wlj (x)
irlj (x)
iwlj (x)
riwlj (x)
rli (x) wli (x) irli (x) iwli (x) riwli (x)
√
√
—
—
—
—
—
—
—
—
√
√
√
√
—
√
√
—
—
—
√
—
—
—
—
VL Datenbank-Implementierungstechniken – 8–22
Ablauf des hierarchischen Sperren
1. Sperren werden auf einem Pfad in der Reihenfolge von
der Wurzel zum Zielobjekt gesetzt
2. Datenobjekt, auf dem gearbeitet werden soll, wird
gesperrt: Schreib- oder Lesesperre (dabei
Sperrenverträglichkeitsmatrix beachten!)
3. Alle anderen Knoten auf dem Pfad bekommen
intentionale Sperren
4. Sperren können verschärft werden, das heißt ein rl kann
zum wl werden, ein irl zum rl und ein irl zum iwl
5. Freigabe erfolgt in umgekehrter Reihenfolge
VL Datenbank-Implementierungstechniken – 8–23
Hierarchisches Sperren: Beispiel I
T1
T2
BetriebsDB
Mitarbeiter
rl (implizit)
Gehalt, ..., Telefon
rl (implizit)
iwl (explizit)
(BetriebsDB)
Relation
rl (explizit)
Tamara, ..., Mario
BetriebsDB
Datenbank
irl (explizit)
Tupel
(Tamara Jagellowsk)
Attribut
(Gehalt)
...
Relation
...
(Mitarbeiter)
...
(Projekt)
Mitarbeiter
iwl (explizit)
Tupel
(Mario De Monti)
Attribut
(Telefon)
VL Datenbank-Implementierungstechniken – 8–24
Hierarchisches Sperren: Beispiel II
T1
T2
BetriebsDB
Mitarbeiter
Tamara
Gehalt
rl (explizit)
iwl (explizit)
(BetriebsDB)
Relation
irl (explizit)
irl (explizit)
BetriebsDB
Datenbank
irl (explizit)
Tupel
(Tamara Jagellowsk)
Attribut
(Projekt)
Tupel
...
(Mario De Monti)
Mitarbeiter
iwl (explizit)
Tamara
iwl (explizit)
Telefon
Attribut
...
(Gehalt)
Relation
...
(Mitarbeiter)
wl (explizit)
(Telefon)
VL Datenbank-Implementierungstechniken – 8–25
Hierarchisches Sperren: riwl
T1 sperrt
T2 sperrt
BetriebsDB
Mitarbeiter
riwl (explizit)
BetriebsDB
Datenbank
riwl (explizit)
irl (explizit)
(BetriebsDB)
Relation
...
(Mitarbeiter)
Relation
(Projekt)
Mitarbeiter
irl (explizit)
Tamara, ..., Mario
rl (implizit)
Tamara
wl (explizit)
Tupel
(Tamara Jagellowsk)
...
Tupel
(Mario De Monti)
Mario
rl (explizit)
VL Datenbank-Implementierungstechniken – 8–26
Sperren in Indexstrukturen
Baumprotokoll
1. Objekt o kann nur dann von T gesperrt werden, wenn
sein direkter Vorgänger bereits von T gesperrt ist
2. erste Regel gilt nicht für die erste Sperre einer
Transaktion
3. Sperren können jederzeit wieder freigegeben werden
4. Kein Objekt kann innerhalb einer Transaktion T zweimal
gesperrt werden
VL Datenbank-Implementierungstechniken – 8–27
Beispiel Baumprotokoll
lock A; lock B ; unlock A; lock D
A
B
C
D
E
F
G
VL Datenbank-Implementierungstechniken – 8–28
Ablauf im Baumprotokoll
T1
lock A
lock B
lock D
unlock B
T2
T3
lock B
lock C
lock E
unlock D
lock F
unlock A
lock G
unlock C
unlock E
lock E
unlock F
unlock B
unlock G
unlock E
VL Datenbank-Implementierungstechniken – 8–29
Baumprotokolleigenschaften
Baumprotokoll erzwingt nicht 2PL!
Falls alle Transaktionen dem Baum-Protokoll genügen, ist jeder korrekte Schedule serialisierbar.
VL Datenbank-Implementierungstechniken – 8–30
Nicht-sperrende Verfahren
■
Zeitstempelbasierte Verfahren erzwingen eine korrekte
Reihenfolge der Bearbeitungsschritte mittels geeigneter
Markierungen der Transaktionen
■
Serialisierbarkeitstester verwalten einen Konfliktgraphen,
und realisieren daher eine direkte Überprüfung der
Konfliktserialisierbarkeit
■
Zertifikatoren führen zunächst die kompletten
Transaktion aus und versuchen erst am Ende
festzustellen, ob die Transaktion gemäß dem
Serialisierbarkeitsbegriffs abgelaufen sind
VL Datenbank-Implementierungstechniken – 8–31
Zeitmarkenverfahren
■
Zeitmarken sind eindeutig und werden fortlaufend
vergeben.
■
Für jedes Datenobjekt x werden zwei Werte geführt:
◆ max-r-scheduled[x]:
Variable, die den Zeitstempel der letzten
Leseoperation auf x enthält
◆ max-w-scheduled[x]:
Variable, die den Zeitstempel der letzten
Schreiboperation auf x enthält
VL Datenbank-Implementierungstechniken – 8–32
Timestamp-Ordering-Regel
Eine Operation pi [x] wird vor qk [x] genau dann ausgeführt, wenn ts(Ti ) < ts(Tk ) gilt.
■ p
und q : inkompatible Operationen der Transaktionen T i
bzw. Tk (i 6= k ) auf einem Objekt x
■ ts(Ti )
bzw. ts(Tk ) sind Zeitstempel der Transaktionen Ti
bzw. Tk
■
Formal:
Sind pi (x) und qj (x) in Konflikt, so gilt:
pi (x) wird vor qj (x) ausgeführt ⇐⇒ ts(Ti ) < ts(Tj ).
VL Datenbank-Implementierungstechniken – 8–33
Basis-TO-Algorithmus
if pi [x] ist eingetroffen then
if pi [x] ist ri [x] then
if ts(Ti ) < max-w-scheduled[x] then
weise Operation zurück;
else
max-r-scheduled[x] :=
max(max-r-scheduled[x], ts(Ti ));
gebe Operation weiter;
else /* pi [x] ist wi [x] */
if ts(Ti ) < max-w-scheduled[x] or
ts(Ti ) < max-r-scheduled[x] then
weise Operation zurück;
else
max-w-scheduled[x] := ts(Ti );
gebe Operation weiter;
VL Datenbank-Implementierungstechniken – 8–34
Nachteile und Vorteile der TO-Verfahren
■
Nachteil: Anfälligkeit gegen stark variierende Laufzeiten
von Transaktionen
◆ lang andauernde Transaktionen bearbeiten ihre
letzten Schritte längere Zeit nach der Vergabe der
Zeitmarke
◆ kommen damit mit diesen Schritten mit größerer
Wahrscheinlichkeit „zu spät“
■
Vorteil: einfache Realisierung in verteilten Systemen
VL Datenbank-Implementierungstechniken – 8–35
Zeitmarkenverfahren: Ablauf
T1
ts = 200
T2
ts = 150
T3
ts = 175
read B
read A
read C
write B
A
B
C
mrs
mws
mrs
mws
mrs
mws
0
0
0
0
0
0
0
0
200
0
0
0
150
0
200
0
0
0
150
0
200
0
175
0
150
0
200
200
175
0
150
200
200
200
175
0
write C ⇓
150
200
200
200
175
⇓
abort
150
200
200
200
175
0
write A
VL Datenbank-Implementierungstechniken – 8–36
Optimiertes Zeitmarkenverfahren
Optimierte BTO-Regel:
■
bei negativen Ausgang des Vergleichs einer
schreibenden Transaktion mit der
max-w-scheduled-Marke wird das Schreiben ignoriert
sofern kein Konflikt mit der max-w-scheduled-Marke
auftritt
■
alter Wert von max-w-scheduled wird übernommen und
die Transaktion läuft weiter
; „Optimierung für blindes Schreiben“
VL Datenbank-Implementierungstechniken – 8–37
Opt. Zeitmarkenverfahren: Ablauf
T1
ts = 200
T2
ts = 150
T3
A
mws
mrs
mws
0
0
0
0
150
0
0
0
ts = 175
read A
C
mrs
read C
150
0
175
0
200
175
0
write A
150
√
150
200 (⇓)
175
0
write A
√
VL Datenbank-Implementierungstechniken – 8–38
Livelocks im Zeitmarkenverfahren
T1
ts = 100
T2
ts = 110
T10
ts = 120
T20
ts = 130
write B
write A
read A ⇓
write B
read B ⇓
write A
read A ⇓
A
B
mrs
mws
mrs
0
0
0
mws
0
0
0
0
100
0
110
0
100
0
110 ⇓
0
100
0
110
0
120
0
110
0
120 ⇓
0
130
0
120
0
130 ⇓
0
120
VL Datenbank-Implementierungstechniken – 8–39
Serialisierbarkeitsgraphentester
Problem: Bereinigen des Konfliktgraphens
r0 (x) w1 (x)w1 (y1 )c1 ... wn (x)wn (yn )cn w0 (z)
|
{z
} |
{z
}
T1
Tn
t
0
t
t
1
2
.
.
.
t
n
VL Datenbank-Implementierungstechniken – 8–40
Optimistische Verfahren: Phasen
1. Ausführungsphase (execute): Transaktion wird
ausgeführt, d.h. alle Lese- und Schreiboperationen;
Schreiboperationen jedoch nicht in der Datenbank,
sondern auf einer lokalen Kopie des Datenbankobjekts
im Puffer
2. Validierung (validate)
für jede Transaktion, die commit ausführen will, wird
geprüft, ob sie im Sinne der Konfliktserialisierbarkeit
korrekt abgelaufen ist
3. Persistenzphase (persist):
falls keine Konflikte aufgetreten sind, Zurückschreiben
aller geänderten Datenbankobjekte in den stabilen
Speicher (d.h. in die Datenbank)
VL Datenbank-Implementierungstechniken – 8–41
Validierungskriterium
Transaktionszähler T C
∀Ti , Tj : n(Ti ) < n(Tj ) mit
n(Ti ) =Wert von TC nach der Validierung von Ti :
1. Ti beendet seine valpersist-Phase, bevor Tj
diese beginnt.
2. x ∈ ws(Ti ) ∩ rs(Tj ) ⇒ Ti beendet
valpersist-Phase, bevor Tj x liest.
3. x ∈ rs(Ti ) ∩ ws(Tj ) ⇒ Ti liest x vor Beginn der
valpersist-Phase von Tj
ws(Ti) ist write-set von Ti (alle von Ti geschriebenen
DB-Objekte)
rs(Ti ) ist read-set von Ti (gelesene DB-Objekte)
VL Datenbank-Implementierungstechniken – 8–42
Optimistische Scheduler
execute
T
1
T
2
T
3
T
1
T
2
T
3
execute
execute
validate
validate
validate
persist
persist
Rückwärtsvalidierung
persist
execute
validate
persist
execute
Vorwärtsvalidierung
execute
VL Datenbank-Implementierungstechniken – 8–43
Optimistische Scheduler II
■
Rückwärtsvalidierung:
◆ Test von rs(Ti ) gegen ws(Tj ) für bereits
abgeschlossene Tj
◆ ausgenommen davon sind Tj , die bereits vor Beginn
von Ti ein commit ausgeführt haben
◆ bei Konflikt: Zurücksetzen von Ti
◆ im Beispiel: Test von rs(T1 ) gegen ws(T2 ) und ws(T3 )
■
Vorwärtsvalidierung
◆ Test von ws(Ti ) gegen rs(Tj ) für Transaktionen Tj , die
aktiv sind (also in der Ausführungsphase)
◆ bei Konflikt: Zurücksetzen von Tj
◆ im Beispiel: ws(T1 ) gegen rs(T2 ) und rs(T3 )
VL Datenbank-Implementierungstechniken – 8–44
Multiversionen-Synchronisation
■
engl. multiversion concurrency control (MVCC)
■
Umsetzung in Oracle, InterBase, PostgreSQL, . . .
■
Motivation
◆ Geg. Schedule s:
s = r1 (x)w1 (x)r2 (x)w2 (y)r1 (y)w1 (z)c1 c2
– s 6∈ CSR
– aber tolerierbar, wenn r1 (y) alte Version von y
lesen könnte, so dass r1 (y) konsistent zu r1 (x) ist
– dann: s äquivalent zu s0 = t1 t2
VL Datenbank-Implementierungstechniken – 8–45
MVCC: Prinzip
■
jede Änderungsoperation w erzeugt neue Version des
Datenobjektes
■
Leseoperationen können Version wählen
■
Versionen sind transparent für Applikationen
■
Vorteile:
Entkopplung von Lese- und Änderungsoperationen ;
Lesetransaktion hat Sicht auf Datenbank wie bei BOT
◆ keine Synchronisation von Lesetransaktionen sowie
gegen Lesetransaktionen notwendig ; Reduzierung
der Konfliktwahrscheinlichkeit
◆ Synchronisation von Änderungsoperationen durch
andere Verfahren (Sperrverfahren,
Zeitstempelverfahren, etc.)
◆
VL Datenbank-Implementierungstechniken – 8–46
MVCC: Beispiel
T1
T2
w(x0 → x1 )
w(y0 → y1 )
TR
r(y0 )
commit
w(x1 → x2 )
commit
r(x0 )
VL Datenbank-Implementierungstechniken – 8–47
MVCC: Versionenverwaltung
■
Aufgabe: Bestimmung der zu lesenden Version
globaler Transaktionszähler T N C (transaction
number count)
◆ Commit-Zeitstempel cts und BOT-Zeitstempel bts für
Transaktion
◆ Schreibzeitstempel wts(x) für Objekt x
◆
VL Datenbank-Implementierungstechniken – 8–48
MVCC: Versionenverwaltung (II)
■
Commit einer Änderungstransaktion TU :
aktueller T N C -Wert als Commit-Zeitstempel cts
sowie Inkrementieren von T N C
◆ modifiziertes Objekt: Schreibzeitstempel
wts(x) = cts(TU )
◆
■
Lesetransaktion TR :
◆ aktueller T N C -Wert als BOT-Zeitstempel:
bts(TR ) = T N C
◆ hat Zugriff auf jüngste Version von x mit:
wts(x) < bts(TR )
VL Datenbank-Implementierungstechniken – 8–49
MVCC: Versionenverwaltung (III)
■
Aufgabe: Freigabe nicht mehr benötigter Versionen
(garbage collection)
BOT-Zeitstempel der ältesten Lesetransaktion:
bts_min
◆ Version xi von Objekt x kann gelöscht werden, falls
neuere Version xj existiert, so dass gilt:
◆
wts(xi ) < wts(xj ) < bts_min
VL Datenbank-Implementierungstechniken – 8–50
Transaktionen in SQL-DBS
Aufweichung von ACID in SQL-92: Isolationsebenen
set transaction
[ { read only | read write }, ]
[isolation level
{ read uncommitted |
read committed |
repeatable read |
serializable }, ]
[ diagnostics size ...]
Standardeinstellung:
set transaction read write,
isolation level serializable
VL Datenbank-Implementierungstechniken – 8–51
Bedeutung der Isolationsstufen
read uncommitted
◆ schwächste Stufe: Zugriff auf nicht geschriebene
Daten, nur für read only Transaktionen
◆ statistische und ähnliche Transaktionen (ungefährer
Überblick, nicht korrekte Werte)
◆ keine Sperren → effizient ausführbar, keine anderen
Transaktionen werden behindert
■ read committed
◆ nur Lesen endgültig geschriebener Werte, aber
nonrepeatable read möglich
■ repeatable read
◆ kein nonrepeatable read, aber Phantomproblem kann
auftreten
■ serializable
◆ garantierte Serialisierbarkeit
■
VL Datenbank-Implementierungstechniken – 8–52
Isolationsebenen II
Isolationsebene
Dirty
Unrepeatable
Phantom
Read
Read
Read
Read Uncommitted
+
+
+
Read Committed
–
+
+
Repeatable Read
–
–
+
Serializable
–
–
–
VL Datenbank-Implementierungstechniken – 8–53
Oracle I
■
Unterstützung der Isolationsebenen Read Committed
und Serializable
■
darüber hinaus: Read-Only-Modus (nicht Bestandteil
von SQL-92)
set transaction isolation level read committed;
set transaction isolation level serializable;
set transaction isolation level read only;
VL Datenbank-Implementierungstechniken – 8–54
Oracle II
Isolationsebenen für eine Menge von Transaktionen
alter session
set isolation_level Isolationsebene;
Explizite Kommandos zum Setzen von Sperren
lock table Tabelle in row share mode;
lock table Tabelle in share mode;
lock table Tabelle in row exclusive mode;
lock table Tabelle in share row exclusive mode;
lock table Tabelle in exclusive mode;
VL Datenbank-Implementierungstechniken – 8–55
Verteilte Transaktionen
VL Datenbank-Implementierungstechniken – 8–56
Anforderungen an verteiltes Commit
VL Datenbank-Implementierungstechniken – 8–57
Zwei-Phasen-Commit-Protokoll
VL Datenbank-Implementierungstechniken – 8–58
2PC: Ablaufschema
VL Datenbank-Implementierungstechniken – 8–59
2PC: Zustandsübergänge
VL Datenbank-Implementierungstechniken – 8–60
2PC: Probleme
VL Datenbank-Implementierungstechniken – 8–61
Varianten des 2PC
VL Datenbank-Implementierungstechniken – 8–62
Drei-Phasen-Commit-Protokoll
VL Datenbank-Implementierungstechniken – 8–63
Verteilte Synchronisation
VL Datenbank-Implementierungstechniken – 8–64
Zeitmarkenverfahren
VL Datenbank-Implementierungstechniken – 8–65
Transaktionen auf Replikaten
VL Datenbank-Implementierungstechniken – 8–66
Deadlock-Erkennung
VL Datenbank-Implementierungstechniken – 8–67
Transaktionsmonitore
Presentation Server
Presentation Server
Workflow Controller
Transaction Server
Transaction Server
VL Datenbank-Implementierungstechniken – 8–68
Transaktionsmonitore: Architektur
■
Präsentations-Server, engl. presentation server
realisiert als Client die Kommunikation mit dem
Anwender (Kommandosprache oder Menü-gesteuerte
Oberflächen zum Absetzen von Transaktionen etc.)
■
Workflow-Kontroller (engl. workflow controller ) erzwingt
die Zuteilung (engl. routing) der
Transaktionsanforderungen an verschiedenen DBMS
und realisiert z.B. das Zwei-Phasen-Commit-Protokoll
■
Transaktions-Server (engl. transaction server )
realisieren die Kopplung der lokalen DBMS mit dem
Transaktionsmonitor
VL Datenbank-Implementierungstechniken – 8–69
Vorteile eines Transaktionsmonitors
■
bietet eine einheitliche Schnittstelle für die
Transaktionsprogrammierung auf verschiedenen DBMS
■
bei verteilter Verarbeitung Übernahme der Routing der
Transaktionen und der Erzwingung von
Commit-Protokollen
■
Übernahme von Systemfunktionen wie
Lastbalancierung, Fehlerkontrolle und
Systemkonfiguration
■
kann Funktionen wie das Schreiben eines Log-Buchs
oder die Kommunikationsüberwachung übernehmen
■
Transaktions-Server eines TP-Monitors kann auch Daten
einkapseln, die nicht von einem DBMS mit voller
Transaktionsfunktionalität verwaltet werden
VL Datenbank-Implementierungstechniken – 8–70