Übungen zur Vorlesung. Datenbanken I. WS 2002/2003 Blatt 4 MUSTERLÖSUNG

Transkript

1 Prof. Dr. S. Böttcher Adelhard Türling Übungen zur Vorlesung Datenbanken I WS 2002/2003 Blatt 4 MUSTERLÖSUNG Aufgabe 4.1: Bestimmen Sie zu den folgenden Transaktions-Schedules, ob diese (konflikt-) serialisierbar sind. Falls ja, geben Sie ein äquivalentes serielles Schedule an. Falls nein, begründen Sie dies: a) b) T 3 T 4 read(c) T 3 read(c) Der Abhängigkeitsgraph des Schedules a) sieht wie folgt aus: a, c a, c b, c b b T 3 T 4

2 Das Schedule a) ist konflikt-serialisierbar, weil der Abhängigkeitsgraph keinen Zyklus enthält -> es ist serialisierbar. Das Schedule a) ist äquivalent dem seriellen Schedule T 1 T 3 T 4 T 2. Der Abhängigkeitsgraph des Schedules b) sieht wie folgt aus: a, b a a, c a T 3 Das Schedule b) ist nicht konflikt-serialisierbar, weil der Abhängigkeitsgraph den Zyklus T 2 T 3 T 2 enthält. Schreiben T 2 und T 3 unterschiedliche Werte für a so kann es keinen seriellen Ablauf geben, da es zwischen T2 und T3 eine beidseitige Abhängigkeit auf a gibt. Aufgabe 4.2: Sowohl die Methodik der Validierung als auch die Methodik der Benutzung von Locks verhindern teilweise Parallelität, die nach dem Konzept der Serialisierbarkeit möglich wäre. Zeigen Sie an einem möglichst einfachem Beispiel, dass es parallele Abläufe von Transaktionen gibt, bei denen die 2-Phasigkeit unnötig Parallelität verhindert. Anders formuliert: Schreiben Sie einen möglichst einfachen Beispielablauf zweier 2-phasiger Transaktionen auf, bei dem eine Transaktion (unnötig) auf die andere wartet, weil die andere Transaktion 2-phasig sperrt, der aber auch serialisierbar wäre, wenn die andere Transaktion beim Sperren nicht 2-phasig vorginge. Das folgende Schedule ist serialisierbar (T 1 T 2 ), beim 2-phasigen Sperren muss aber die Transaktion T 1 (mit ihrem lock(a)) auf der Transaktion T 2 warten. Nach dem 2PC Protokoll darf T 2 aber erst ein unlock auf a ausführen nachdem die Sperre auf b angefordert ist.

3 Aufgabe 4.3: Neben Read- und Write-Locks gibt es noch das Konzept zusätzlicher Upgrade-Locks. Ein Upgrade-Lock erlaubt den lesenden Zugriff auf eine Relation und enthält eine Option auf ein späteres Write-Lock, d.h. die Transaktion darf später noch ein Write-Lock auf diese Relation einfordern. Eine Spezialform des Upgradelocks sieht folgendermaßen aus: Ein Upgrade-Lock verträgt sich nur einseitig mit Read-Locks anderer Transaktionen: Hat eine Transaktion T 1 ein Read-Lock(A) gemacht, so wird trotzdem ein folgendes Upgrade-Lock(A) einer Transaktion T 2 erlaubt. Hat anders herum eine Transaktion T 1 ein Upgrade-Lock(A) gemacht, so muss eine Transaktion T 2 mit einem späteren Read-Lock(A) warten, bis das Upgrade-Lock wieder freigegeben wurde. Geben Sie ein Beispiel eines parallelen Ablaufs zweier Transaktionen an, bei dem der Einsatz eines Upgrade-Locks Vorteile bringt.

4 ohne upgrade-lock readlock(a) writelock(a) mit upgrade-lock readlock(a) upgradelock(a) writelock(a) Ohne upgrade-lock muss die Transaktion T 2 auf das von Transaktion T 1 warten, bevor das writelock(a) gewährt werden kann. Wird statt dessen ein upgrade-lock benutzt werden, so könnte die Transaktion T 2 zumindest schon mal das ausführen bevor T 1 ein ausführt. Führt T 2 zunächst nur ein Readlock(a) aus und später erst ein writelock(a), ist T2 genauso schnell wie mit upgrade lock, jedoch nicht mehr deadlock-sicher. Aufgabe 5.1: Sperrende Transaktionen: um Deadlock-frei zu sperren, wurde in der Vorlesung vorgestellt, dass die Relationen R 1, R 2,..., R n global angeordnet werden und benötigte Sperren in der Reihenfolge dieser Ordnung angefordert werden. Man könnte durch einen Widerspruchbeweis zeigen, dass diese Anordnung der Betriebsmittel zyklische Wartegraphen verhindert, also Deadlock-Freiheit garantiert. a) Wenn man zwischen Readlock(A) und Writelock(A) unterscheiden will und Deadlock-freies Sperren erweitern will auf Readlock- und Writelock-Operationen, in welcher Reihenfolge muss jede Transaktion dann ihre Sperranforderungen anordnen, um Deadlocks zu vermeiden?

5 Man muss die üblichen Sperr-Regel um eine zusätzliche Regel erweitern: Eine Transaktion darf nie ein Writelock(A) anfordern, nachdem sie Readlock(A) angefordert hat. Mit anderen Wörtern: Jede Transaktion darf die Sperren nur in einer strikt wachsenden Reihenfolge anfordern (unabhängig davon, ob das Lese- oder Schreibsperren sind). Ohne diese Regel landen die folgenden zwei Transaktionen in Deadlock: T1 T2 Readlock(X) Readlock(X) Writelock(X) Writelock(X) b) Ergänzen Sie folgende Transaktion um Readlock- und Writelock-Befehle (Unlock braucht nicht extra eingetragen zu werden): read(r 2 ); read(r 1 ); write(r 3 ); read(r 4 ); write(r 4 ); readlock(r 1 ); readlock(r 2 ); read(r 2 ); read(r 1 ); writelock(r 3 ); write(r 3 ); writelock(r 4 ); read(r 4 ); write(r 4 ); Aufgabe 5.2: Es gibt bei einer fortgeschrittenen Stufe von Embedded SQL (beim so genannten dynamischen SQL) die Möglichkeit, eine SQL-Query zur Laufzeit von der Tastatur einzulesen.

6 Wenn Sie Transaktionen, die teilweise aus dynamischem SQL bestehen, durch Sperren synchronisieren wollten, welche Strategie würden Sie zur Behandlung von Deadlocks wählen? (Begründung, 1 Satz.) Bei einem vorher unbekannten Ablauf einer Transaktion können Deadlocks nicht vermieden werden. Eine Deadlock-Erkennung Strategie mit einer Deadlock-Behandlung muss realisiert werden. Kann man die Reihenfolge der benutzten Objekte vorgeben so ist die Anordnung der Betriebsmittel zur Vermeidung von Deadlocks die beste Wahl, da Benutzer Eingaben nie doppelt ausführen müssen. Aufgabe 5.3: Sowohl die Methodik der Validierung als auch die Methodik der Benutzung von Locks verhindern teilweise Parallelität, die nach dem Konzept der Serialisierbarkeit möglich wäre. Geben Sie ein möglichst einfaches Beispiel für einen parallelen Ablauf zweier Transaktionen an, der serialisierbar wäre, bei dem aber trotzdem in der Validierungsphase eine Transaktion zurückgesetzt wird. T1 start validierung T2 start validierung schreiben Bei der Validierung von T1 wird die Transaktion T1 abgebrochen, weil T1 von T2 gelesen hat und T2 die Validierung/Schreibphase schon angefangen hat. Der Ablauf ist aber serialisierbar. In diesem konkreten Fall ist also der Abbruch der Transaktion T1 nicht notwendig: T2 ->T1.