Kap 10: Grundlagen moderner Transaktionsmodelle und

aaa
Kap 10: Grundlagen moderner Transaktionsmodelle
und -Verarbeitung
Zielsetzung: Vertieftes Verständnis der wesentlichen Ideen
und Konzepte, die in Produkten und aktuellen
Forschungsarbeiten diskutiert und angeboten werden.
Inhalt:
• Nochmals (Wiederholung aus IS-G): Was ist eine
Transaktion?
• „Semantische Serialisierbarkeit“
• Mehrebenen- Transaktionen
GrundTA-1
ISK
10.1 Einführung und Problemstellung
Le
se
sto
f
f
Beispiel-Transaktion - 1
Read/Write
BOT
Read (p)
Read/Write-Modell:
Write (p)
Read (s)
Es werden nur die Operationen
Read und Write betrachtet auf
Seiten- (oder Datensatz-) Objekten
des Datenbankpuffers. Man spricht
auch von physischen Objekten.
Write (t)
Dies war das Modell in IS-G
Write (q)
EOT
ISK
GrundTA-2
1
aaa
Le
se
sto
f
Beispiel-Transaktion - 2
f
SQL
BOT
SQL Transaktion:
Select A, B from R
where ...
Update R set...
where...
Insert into S values...
Delete from S
where...
EOT
In Wirklichkeit werden
Transaktionen durch den
Programmierer an der DB, z.B.
SQL-Schnittstelle definiert.
Eine Transaktion im
Read/Write-Modell entsteht
dann durch Abbildung der
SQL-Anweisungen auf eine
Folge von Reads und Writes
auf Seiten.
GrundTA-3
ISK
Beispiel-Transaktion - 3
Application Services
Le
se
sto
f
f
BOT
Withdraw (...)
if Balance (...) < 0
Abort _Transaction
else
Deposit (...)
EOT
ISK
Transaktion mit Aufruf von
Anwendungsservices auch
“Transaktion mit semantisch
reichen Operationen” genannt:
Eine Transaktion im Read/WriteModell entsteht durch die
Abbildung der AnwendungsServices auf die SQL-Schnittstelle
und von dort auf die Read/WriteOperationen.
GrundTA-4
2
aaa
Le
se
sto
f
Beispiel-Transaktion - 4
f
BOT
EnterCreditApplication(...)
CheckBonity(...)
if Amount (...) large
GlobalRiskAssessment(...)
if ok
ExecutiveApproval(...)
else
LocalRiskCheck(...)
if ok
LocalApproval(...)
ReportDecision
EOT
Eine Transaktion mit
alternativen Ausführungen:
Eine Transaktion im
Read/Write-Modell ergibt sich
dynamisch durch Abbildung
der Anwendungsservices auf
die DBS-Schnittstelle und
von dort auf die Read und
Write-Operationen.
Bereits im vorigen Beispiel
ergab sich durch Abort eine
andere als die vorgesehene
Ausführung.
GrundTA-5
ISK
Problembewusstsein
Beispiel: Transaktionen mit SQL-Operationen:
t1 = <select * from R where A < 0,
delete from S where B = 0>
… kurz t1 = <p1,q1>
t2 = <select * from S where B = 0,
delete from R where A > 0>
… kurz t2 = <p2,q2>
S = <p2, p1, q1, q2>
ISK
…
ist dieser Ablauf korrekt?
GrundTA-6
3
aaa
Transformation auf die Seitenebene
t2
p2
p1
t1
q1
q2
r2(u) r2(v) r1(s) r1(t) w1(u) w1(v) w2(t) w2(s)
kein serialisierbarer Ablauf von t2 und t1 auf der Seitenebene
Andererseits ist der SQL-Ablauf korrekt, weil p1 nicht in Konflikt
Was ist korrekt??
mit q2 ist (Tupelmengen disjunkt!).
GrundTA-7
ISK
Beobachtungen und offene Fragen
• Kann man Transaktionsverwaltung (Concurrency Control und Recovery)
auch auf einer höheren Ebene ansiedeln, also semantisch reichere
Operationen zulassen? Was ändert sich an den Grundlagen?
===> Semantische Serialisierbarkeit (Kap. 10.2)
• Aktionen innerhalb von Transaktionen werden als atomar angesehen.
Was passiert, wenn Aktionen wieder als Transaktionen angesehen
werden?
===> Mehrebenen-Transaktionen (Kap 10.3)
ISK
GrundTA-8
4
aaa
10.2 Transaktionen mit semantisch reichen Operationen
…Zulassen von Operationen jenseits von Reads/Writes („semantisch
reiche“), Vorbereitung für zusammengesetzte Transaktionen:
DB
Menge von (abstrakten)
“shared” Objekten. Diese
treten nicht explizit auf, sondern nur über die Menge A
A
Menge von DB-Aktionen, also
(semantisch reiche) Operationen, die den Benutzern
zugänglich gemacht wurden.
T
Menge von Transaktionen
( t1, t2,..), die ausgeführt
werden müssen.
partielle Ordnung auf T:
wenn t1 => t2, so wird
gefordert, dass t1 endet
bevor t2 startet.
Üblicherweise (und in IS-G)
haben wir keine solche InterTransaktions-Ordnung für
die Ausführung gefordert.
t
Transaktion, eine Menge von
Aktionen (a1, a2, ...ak) mit
<<t
partielle Ordnung auf t:
wenn a1 <<t a2, wird gefordert,
dass a1 endet bevor a2 startet.
Dies ist die übliche IntraTransaktions- Ordnung, die
sicherstellt, dass Rückgabewerte von a1 für a2 zur
Verfügung stehen.
==>
ISK
GrundTA-9
Die grundlegenden Voraussetzungen
• Jede einzelne Transaktion, wenn • Eine korrekte, isolierte
Ausführung einer Transaktion t ist
allein ausgeführt, ist korrekt. (1)
eine, welche die gegebene
• Wegen (1) ist jede =>-serielle
Ordnung <<t beachtet.
Ausführung aller Transaktionen
korrekt.
(2)
• (1) und (2) sind Axiome. Korrekt- • Eine =>-serielle Ausführung von T
ist eine serielle Ausführung,
heit paralleler Ausführung wird
welche die gegebene Ordnung =>
bewiesen unter der Annahme der
beachtet.
Korrektheit serieller Ausführung
• Konflikt-Aktionen unterschiedlicher Transaktionen müssen
• Wenn a’ and a” beide in t sind,
geordnet werden. (Es kann ja ein
und wenn a’<<t a” vorgeschrieben
Informationsfluss zwischen solist, so kann a’ Werte zurückgeben,
chen Transaktionen bestehen)
die für a” benötigt werden (siehe
dazu das Read/Write-Modell, wo
• Aktionen innerhalb einer
wir annehmen, dass ein Write von
Transaktion, wenn <<t-geordnet,
allen davor angeordneten Reads
dürfen nicht kommutiert werden,
dieser Transaktion abhängt)
auch wenn sie konfliktfrei sind.
ISK
GrundTA-10
5
aaa
Konflikte & Kommutativität
• Kommutativität:
Aktionen a' and a" aus A sind konflikt-frei genau dann, wenn die Folgen
und
F1 << a' << a"
<< F2
F1 << a" << a'
<< F2
die gleiche Werte zurückgeben für alle Aktionsfolgen F1 and F2, die aus
Aktionen von A gebildet werden können.
Wir können keinerlei Unterschiede beobachten, ob a’ vor a” ausgeführt
wurde oder umgekehrt. Daher kann ein Scheduler a’ and a” in beliebiger
Reihenfolge ausführen.
• Konfliktfreie Aktionenpaare sind kommutierbar. Nicht kommutierbare
Aktionspaare heissen kurz Konfliktpaare: (a‘,a“) ∈ CON
GrundTA-11
ISK
Inverse (Undo) und effektfreie Operationen für Recovery
• Inverse Operation:
Aktion a" ist invers zu a' wenn die Folgen
F1 << a' << a" << F2
und
Le
se
sto
f
f
F1 << F2
die gleiche Werte zurückliefern für alle Aktionsfolgen F1 and F2. Wir
sagen auch, dass a“ eine Kompensation von a‘ ist.
• Effektfreie Aktionssequenzen (Nullsequenzen):
sind solche, die ohne beobachtbaren Einfluss bleiben, also (siehe
Definition vorher)
– Ein Paar (p, p-1 ) bestehend aus Aktion p und ihrer Inverser p-1
– Reine Leseaktionen von Rücksetztransaktionen
• Wir können keinerlei Unterschied beobachten, ob eine effektfreie
Aktionssequenz ausgeführt wurde oder nicht. Daher kann der
Scheduler effektfreie Operationen entfernen!
ISK
GrundTA-12
6
aaa
Semantische Serialisierbarkeit
Sei S = (T, =>, <<) ein Schedule für T mit gegebener Inter-TransaktionsOrdnung => und mit der Ausgabeordnung << , einer partiellen Ordnung,
die über den Aktionen der Transaktionsmenge T definiert ist.
Ein Schedule S ist wohlgeformt, wenn für die Ausgabe-Ordnung << gilt
a) << beachtet die Inter-Transaktions-Ordnung =>,
b) << enthält die Intra-Transaktions-Ordnungen <<t aller t aus T
c) << enthält alle Konflikt-Paare, d.h. wenn a’ in t’ and a” in t” (t’ ≠ t”) und
wenn a’ and a” im Konflikt sind, so muss entweder a’ << a” oder a” << a’
gelten.
Ein Schedule S= (T, =>, <<) ist seriell, wenn die Input-Ordnung => eine totale
Ordnung ist, d.h. es gilt für zwei beliebige unterschiedliche Transaktionen
t’ und t” in T entweder t’ => t” oder t” => t’ .
Ein wohlgeformter Schedule S=(T, =>s, <<s) ist (semantisch) serialisierbar,
wenn ein wohlgeformter serieller Schedule Sser=(T, =>ser, <<ser) existiert,
<<ser ⊇ <<s
für den gilt:
d.h. S ordnet Konflikt-Paare in gleicher Weise wie Sser und die gegebene
Inputordnung ist beachtet.
GrundTA-13
ISK
Serialisierungsgraph und Zusammenstellung
Serialisierungsgraph (wie IS-G): Sei S = (T, =>, <<) ein wohlgeformter
Schedule. Der Serialisierungsgraph SG(S) ist ein gerichteter Graph mit den
Transaktionen als Knoten. Eine Kante von ti nach tj (i ≠ j) gibt es, wenn es eine
Aktion a´ aus ti und a” aus tj gibt mit a´ << a”.
Satz (wie IS-G): Ein Schedule S ist genau dann serialisierbar, d.h. korrekt,
wenn SG(S) azyklisch ist.
Input und Output eines Schedulers
T, =>
A
CON
Scheduler
<<t
τ , <<
ISK
GrundTA-14
7
aaa
Le
se
sto
f
10.3 Ein konkretes Beispiel
f
• Aktionsmenge: Deposit, Withdraw, Read (beachten, dass es unerheblich
ist auf welchen Datenbanken diese Aktionen ausgeführt werden.
Insbesondere könnte es sich um verteilte Datenbanken handeln):
– R (ead):
– W (ithdraw):
– D (eposit):
CON :
R
D
W
x ist KontoNr
a ist Kontostand
b ist Betrag
r ist Fehlerindikator
R (x,a)
W (x,b,r)
D (x,b,r)
Konfliktrelation
(prüfen mittels Kommutativitätsdefinition)
+
+
+
W
+
+
D
+
+
R
+ = konflikt
- = konfliktfrei
GrundTA-15
ISK
Le
se
sto
ff
Auch hier beachten: es ist unerheblich, ob diese Transaktionen verteilt
sind oder nicht. Im Prinzip könnte jede Aktion auf einer anderen DB laufen
Transaktionen im Beispiel
t1 : W (s,a,r);
if r ok
do in parallel
(D (u,a/2,r)
D (v,a/2,r))
t2 : W (s,b,r) ;
if r ok
do in parallel
(D (v,b/2,r)
D(w,b/2,r))
ISK
W1
Du1
Dv1
W2
Dv2
Dw2
GrundTA-16
8
aaa
Le
se
sto
f
Für den Scheduler:
f
t1 = {W1 ,Du1 ,Dv1 | W1 <<t1 Du1
W1 <<t1 Dv1 }
t2 = {W2 ,Dv2 ,Dw2 | W2 <<t2 Dv2
W2 <<t2 Dw2 }
Schedule S:
S = ( {t1 , t2},
=∅,
<< = { W1 << Du1 , W1 << Dv1 ,
W2 << Dv2 , W2 << Dw2 ,
Ordnung vom Programmierer
W1 << W2
})
vorgegeben
Einziges Konfliktpaar unter
allen Kombinationen der
Operationen W1, Du1 Dv1, W2,
Dv2, Dw2
SG(S) daher: t1 --------> t2
also azyklisch, S ist korrekt!
GrundTA-17
ISK
10.4 Mehrebenen-Transaktionen
• Implizite Voraussetzung im
flachen Modell:
Jede Aktion wird atomar und
isoliert ausgeführt, d.h.
vollständig oder gar nicht.
• Wir geben diese Voraussetzung
jetzt auf:
Was passiert, wenn Aktionen
wieder als Transaktionen
betrachtet werden und parallel
ausgeführt werden?
ISK
Warum ist dies wichtig?
• Aktionen können komplex sein,
(nicht nur einige Reads und Writes
einzelner Seiten). Wenn Aktionen
nicht im Konflikt sind, werden sie
in irgendeiner Reihenfolge
sequentiell ausgeführt, warum
nicht (korrekt) parallel?
• Selbst wenn Aktionen (a’,a”) im
Konflikt sind und wir fordern, dass
a’<< a” oder a”<<a’, warum können
wir nicht parallele Ausführung
erlauben, aber mit dem gleichen
Effekt als ob sequentiell
ausgeführt?
GrundTA-18
9
aaa
Das Problem dahinter: Welche Information muss
zwischen mehreren Schedulern übergeben werden?
Transaktionen
G-Scheduler
Aktionen
Transaktionen
L-Scheduler
Aktionen
Wir unterscheiden mehrere Scheduler,
in der Abbildung den G-Scheduler und
den L-Scheduler.
Unser Ziel ist es, die zwei Scheduler so
unabhängig voneinander wie möglich
arbeiten zu lassen.
Wie können wir sicherstellen, dass die
Serialisierungsordnung des LSchedulers der Serialisierungsordnung
des G-Schedulers nicht widerspricht?
Welche verschiedenen Arten von
Ordnungsbeziehungen müssen wir
unterscheiden?
GrundTA-19
ISK
Starke und Schwache Ordnung
• Klassisch unterscheiden wir nur zwei Fälle:
• sequentielle Ausführung A<<B („A vor B“)
• parallele Ausführung A//B, die äquivalent ist zu A<<B oder B<<A
Wenn parallele Ausführung nicht möglich ist, z.B. Im Falle von
Konflikten, wird sequentielle Ausführung erzwungen. Dies ist unnötig
eng!
• Ein verbessertes Modell unterscheidet drei Fälle:
– sequentielle Ausführung A<<B, ab jetzt „starke Ordnung“ genannt,
– uneingeschränkte parallele Ausführung A//B, die äquivalent ist zu
entweder A<<B oder B<<A,
– eingeschränkte parallele Ausführung A<B die äquivalent ist zu A<<B.
Diese (neue) Anordnungsbedingung wird „schwache Ordnung“
genannt. Die Serialisierungsordnung ist ein Beispiel für schwache
Ordnung
• Aus der Definition folgt, dass die Verschärfung einer schwachen zu
einer starken Ordnungsrestriktion immer korrekte Resultate liefert.
ISK
GrundTA-20
10
aaa
Beispiele
1) Übertragung eines Betrages s von Konto a nach Konto b und des
Betrages t von b nach c zweier Transaktion:
Unterschied von
Transfer(a,b,s) // Transfer(b,c,t)
zu
Transfer(a,b,s) < Transfer(b,c,t)
zu
Transfer(a,b,s) << Transfer (b,c,t)
2) Erhöhung des Gehalts aller Mitarbeiter nach folgendem Schema:
Transaktion 1: Erhöhung des Gehalts aller Mitarbeiter um den festen
Betrag s, deren derzeitiges Gehalt unter 2000 liegt.
Transaktion 2: Lineare Erhöhung des Gehalts jedes Mitarbeiters um
5%.
– Unterschiede wie oben?
ISK
GrundTA-21
Konfliktkonsistente Wohlgeformtheit eines Schedules
Behutsamer Umgang mit Ordnungseinschränkungen, Vorbereitung für
Zusammenspiel zweier oder mehrerer Scheduler:
Sei S = (T, =>, ->, <<, <) ein Schedule für T mit geg. starker => und schwacher ->
jeweils partieller Inter-Transaktions-Ordnung mit => ⊆ ->. << bzw. < ist die starke
bzw. schwache partielle Ausgabeordnung, die auf den Aktionen von T definiert
ist.
Ein Schedule S ist wohlgeformt, wenn die Ausgabeordnungen << und < den
folgenden Bedingungen genügen:
a) << beachtet die starke Inter-Transaktions-Ordnung =>,
b) << enthält die starke Intra-Transaktionsordnung <<t für alle t aus T
c) < enthält alle Konflikt-Paare, d.h. wenn a’ aus t’ und a” aus t” (t’ ≠ t”)
und wenn a’ and a” im Konflikt sind, so muss entweder a’< a” oder a”< a’ sein
d) << ⊆ <
Bemerkung: Konfliktkonsistente Wohlgeformtheit erfasst alle
offensichtlichen Anordnungsbedingungen. Andere Schedules werden nicht
betrachtet. Wir beachten, dass die schwache Eingabeordnung -> nicht
automatisch propagiert wird.
ISK
GrundTA-22
11
aaa
Konflikt-konsistente Serialisierbarkeit
Ein Schedule S=(T, =>, ->, <<, <) ist seriell, wenn die starke Eingabeordnung
=> total ist. Offensichtlich ist dann -> und => identisch.
Definition CCSR: Ein wohlgeformter Schedule S=(T, =>s, ->s, <<s, <s) ist
konflikt-konsistent serialisierbar (CCSR), wenn ein wohlgeformter
serieller Schedule Sser=(T, =>ser, ->ser, <<ser, <ser) existiert mit
=>ser ⊇ ->s
<ser ⊇ <s
d.h. S ordnet Konfliktpaare wie Sser und die gegebene starke und schwache
Eingabeordnung wird in S beachtet.
Theorem CCSR:
Ein wohlgeformter Schedule S ist CCSR genau dann, wenn die
Vereinigung des Serialisierungsgraphen SG(S) (wie üblich definiert) mit
der schwachen Inter-Transaktions- Ordnung -> von S azyklisch ist.
GrundTA-23
ISK
CCSR Bemerkungen
1) Der Hauptunterschied zum bisherigen Modell besteht in der
behutsamen Propagierung der schwachen Ordnung: Die schwache
Inter-Transaktions-Ordnung schränkt die erlaubten seriellen Schedules
für den Korrektheitsbeweis ein. Sie wird nicht automatisch propagiert.
Konfliktpaare müssen daher sowohl azyklisch als auch konsistent zur
vorgegebenen schwachen Ordnung angeordnet werden.
2) CCSR ist nur sinnvoll, wenn mehrere Scheduler zusammenarbeiten.
Falls nur ein Scheduler (= „korrekter Parallelisierer“) vorhanden ist,
wird die schwache Ausgabeordnung in eine starke umgewandelt, um so
Korrektheit zu erreichen (es gibt ja keinen Scheduler mehr darunter, der
dafür sorgen kann!)
ISK
GrundTA-24
12
aaa
Anwendung bei Mehrebenen-Schedules
Ein Mehrebenen-Schedule besteht aus n
Schedules wobei:
– Aktionen auf einer Ebene i werden
Transaktionen der nächst tieferen
Ebene i-1,
– die starke Ausgabeordnung auf der
einen Ebene i wird die starke Eingabeordnung der nächst tieferen i-1.
– die schwache Ausgabeordnung auf
einer Ebene i wird die schwache Eingabeordnung der nächst tieferen i-1,
Τ, =>, −>
Scheduler i
τ , << <
i
i
i
Τi−1, =>i-1, ->i-1
Scheduler i-1
Zentraler Satz (unmittelbar aus der Definition):
Ein Mehrebenen-Schedule ist korrekt, wenn jeder individuelle Schedule
CCSR ist.
GrundTA-25
ISK
10.5 Transfer-Beispiel zur Transaktionsverwaltung als ZweiEbenen-Schedule:
Für Scheduler 1 (siehe oben):
t2 = { W2(s, b) <<t2 D2(v, b/2)
t1 = {W1(s, a) <<t1 D1(u, a/2)
<<t1 D1(v, a/2) }
<<t2 D2(w, b/2) }
t1
W1
W2
t2
Du1
Dv2
[Für die Darstellung von S1:
W2
ISK
Dv1
: starke Ordnung
: schwache Ordnung]
SG(S1):
S1:
W1
Dw2
Du1
Dv1
Dv2
Dw2
t1
t2
Serialisierungsgraph ist azyklisch:
Semantische Serialisierbarkeit
GrundTA-26
13
aaa
Übergang zu einem Zwei-Ebenen-Schedule
Die Operationen W1, W2, Du1, Dv1, Dv2, Dw2 werden jetzt nicht mehr als
atomare Operationen betrachtet, sondern als Transaktionen, die einem
Scheduler 2 übergeben werden, der für (lokale) Korrektheit sorgen muss.
Für die Operation W (ithdraw) und D (eposit) soll folgende Implementierung
angenommen werden:
r (ead) (konto) << wr (ite) (konto)
Es soll also vorgängig der Kontostand gelesen und dann geschrieben werden.
Der Scheduler 2 erhält also das Resultat vom Scheduler 1 und regelt die
Lese- und Schreibzugriffe auf den entsprechenden Speicherobjekten.
GrundTA-27
ISK
Ausgabe des Schedulers 1 = Eingabe für Scheduler 2
W1
W2
Du1
Dv2
Dw2
Dv1
r1(s) wr1(s) r2(s) r1(u) wr2(s) r2(v) wr1(u) r2(w) wr2(v) r1(v) wr2(w) wr1(v)
S2:
SG(S2):
r1(s)
r1(u)
wr1(u)
wr1(s)
r1(v)
wr1(v)
r2(s)
r2(v)
wr2(v)
wr2(s)
r2(w)
wr2(w)
: starke Ordnung
: schwache Input-Ordnung
: Konfliktpaar-Ordnung
ISK
W1
Du1
Dv1
W2
Dv2
Dw2
SG(S2) vereinigt mit
schwacher Inputordnung ist
azyklisch, also korrekt
GrundTA-28
14
aaa
Anhang: Einführungs-Beispiel: Prüfung auf Korrektheit
Konflikte bestehen zwischen:
(p1, p2) : kein Konflikt: Leser
(p1, q2) : kein Konflikt, weil Tupelmengen disjunkt
(q1, p2) : Konflikt (nicht disjunkte Tupelmengen)
(q1, q2) : kein Konflikt, weil Tupelmengen disjunkt)
Le
se
sto
f
f
Daher Eingabe für den SQL Scheduler (S1):
Eingabe-Ordnungen:
→=Ø
⇒ =Ø
Intra-Transaktionsordnung:
p1 <<1 q1
p2 <<2 q2
Erzeugte Ausgabeordnungen:
<< :
< :
p1 << q1 , p2 << q2
wegen Intratransaktionsordnung
q1 < p2 (p1 < q1 , p2 < q2 ) weil Konfliktpaar (und wegen << ⊆ <) .
erzeugter Schedule ist korrekt, weil der serielle Schedule t1 ⇒ t2 diese
Ordnungen enthält.
ISK
GrundTA-29
Le
se
sto
Eingabe für den Seitenscheduler (S2):
ff
Konflikte: r/w - Konflikte (siehe IS-G)
Inputordnungen für S2 (= Outputordnung von S1):
⇒ = << :
p 1 ⇒ q 1 , p2 ⇒ q 2
→ = < :
q1 → p2 , (p1 → q1 , p2 → q2)
Intra-Transaktionsordnung: in q1: <<q1 : wq1(u) << wq1(v), in p2: <<p2: r2(u) << r2(v)
wegen Zugriff über einen Index; alle anderen Aktionen in p1 und q2 auf der
Seitenebene können parallel ausgeführt werden.
Ausgabe des Seitenschedulers:
Ausgabeordnungen eines wohlgeformten Schedules:
<< :
rp1(s) << wq1(v) , rp1(s) << wq1(u) , rp1(t) << wq1(v) , rp1(t) << wq1(u)
rp2(u) << wq2(s) , rp2(u) << wq2(t) , rp2(v) << wq2(s) , rp2(v) << wq2(t)
wq1(u) << wq1(v), r2(u) << r2(v)
< :
r p2 (u) < wq1(u), rp2(v) < wq1(v)
...
Dies wäre zwar wohlgeformt, allerdings ein nicht korrekter Schedule, weil die
Konfliktpaarordnung im Widerspruch zur schwachen Inputordnung wäre, die ja
verlangt: q1 → p2 (siehe folgende grafische Darstellung)
ISK
GrundTA-30
15
aaa
Le
se
sto
f
Grafische Darstellung:
p1
rp1(s)
rp2(u)
f
q1
rp1(t)
rp2(v)
p2
wq1(u)
wq2(t)
wq1(v)
wq2(s)
Konfliktpaarordnung
widerspricht der schwachen
Inputordnung
.
Schedule ist also NICHT
korrekt
q2
Konfliktpaarordnung
schwache Inputordnung
starke Ordnung
GrundTA-31
ISK
Le
se
sto
f
daher “lieber” Konfliktpaare so ordnen:
wq1(u) < rp2(u)
wq1(v) < rp2(v)
rp1(s) < wq2(s)
rp1(t) < wq2(t)
p1
rp1(s)
rp2(u)
p2
ISK
q1
rp1(t)
rp2(v)
wq1(u)
wq2(t)
q2
wq1(v)
wq2(s)
f
Prüfung auf CCSR :
SG (S2):
p1
q1
p2
q2
SG(S) ∪ mit Inputordnung ist
azyklisch d.h. CCSR
GrundTA-32
16