Optimistic and Multiversion Concurrency Control

Transkript

1 Optimistic and Multiversion Concurrency Control Am Beispiel PostgreSQL Seminar Datenbanksysteme Master of Science in Engineering Vertiefung Software and Systems HSR Hochschule für Technik Rapperswil Supervisor: Prof. Stefan Keller Autor: Gian Poltéra Rapperswil, Juni 2014 Version: 1.3

2 Zusammenfassung Im Rahmen dieser Seminararbeit wurde in einem ersten Teil das Paper von Momjian [1] studiert und versucht die wesentlichen Punkte verständlich zu erläutern. Dieses Paper befasst sich mit Multiversion Concurrency Control (MVCC) in PostgreSQL. MVCC ist ideal für stark ausgelastete Datenbanken in denen sehr häufig nur gelesen wird. Das Besondere an MVCC ist, dass nie auf ein Datenbankobjekt gewartet werden muss, da verschiedene Versionen eines Objekts gehalten werden. In einem Versuch, die Geschwindigkeit mit und ohne MVCC zu messen, wurde ein erheblich höherer Zeitbedarf bei der Durchführung von Updates mit MVCC festgestellt. Dies ist, neben dem erhöhten Platzbedarf, einer der Nachteile von MVCC. Ergänzt werden die theoretischen Erläuterungen jeweils mit praktischen Beispielen. Im zweiten Teil dieser Seminararbeit wurde versucht, diverse Anomalien gemäss Paper von Berenson et al. [2], in PostgreSQL zu simulieren. Zuerst wurden diese Anomalien theoretisch erläutert und anschliessend wurde für Demo-Zwecke ein kleines Java Programm geschrieben. Es konnten erfolgreich drei Anomalien erzeugt werden. Abstract In a first part of this seminar, the paper written by Momjian [1] has been studied. Key points of the paper have been identified and described in a comprehensible manner. This paper is concerned with multiversion concurrency control (MVCC) in PostgreSQL. MVCC is ideally suited for heavily used databases on which mainly read accesses occur. A special feature of MVCC is that database objects are always immediately ready for access with no delays. This is because different versions of the object are kept in the database at the same time. In an attempt to measure the speed with and without MVCC used, a considerably higher time requirement was detected to perform updates. This is, in addition to the increased space requirement, one of the downsides of MVCC. The theoretical explanations in the paper are each accompanied with practical examples. In the second part of this seminar paper, it was tried to simulate the various anomalies described in the paper of Berenson et al. [2]. This was done by first explaining those anomalies in detail. Afterwards, small demo applications written in Java have been created in order to verify them. From all of the anomalies described, three could be successfully simulated. 2

3 Inhaltsverzeichnis 1 Einführung und Überblick OCC MVCC Vor- und Nachteile von MVCC Geschwindigkeit von MVCC MVCC in PostgreSQL Grundlagen INSERT DELETE UPDATE ROLLBACK Statusmarkierungen Multi-Statement Transaktionen Cleanup Praktischer Teil Grundlagen Dirty Read Nonrepeatable Read Phantom Read Lost Update Read Skew Write Skew Fazit und Ausblick Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Anhang Planning MSSQL Snapshot Test Documentation Classes Source Code

4 1 Einführung und Überblick 1.1 OCC Beim Optimistic Concurrency Control (OCC) wird allen Benutzern einen parallelen Lesezugriff auf die Datensätze gewährt. Es wird der Benutzer privilegiert, der zuerst einen Datensatz geändert hat. OCC ist vorwiegend für Lesezugriffe geeignet. Beim Pessimistic Concurrency werden beim Zugriff auf ein Objekt, die Schreib- und Lesezugriffe für alle anderen Benutzer gesperrt. 1.2 MVCC Das Multiversion Concurrency Control (MVCC) ist eine Erweiterung von OCC. Es kommt ohne Blockierung und ohne die Konsistenz der Datenbank zu gefährden aus. Dabei muss eine Transaktion nie auf ein Datenbankobjekt warten. Dies wird intern durch die Haltung von verschiedenen Versionen des Objekts gelöst. MVCC ist ideal für stark ausgelastete Datenbanken in denen sehr häufig nur gelesen wird. Die meisten aktuellen Datenbanksysteme, wie PostgreSQL, Oracle, DB2, MySQL InnoDB und MSSQL (optional) unterstützen MVCC [1]. Das Verhalten von MVCC wird mithilfe der Abbildung 1 anhand eines Beispiels erläutert. INSERT CREATE 40 EXPIRE DELETE CREATE 40 EXPIRE 47 UPDATE CREATE 40 EXPIRE 78 CREATE 78 EXPIRE alt (delete) neu (insert) Ein neuer Wert wird in die Datenbank geschrieben. Es wird der Wert der aktuellen Transaktions-ID in CREATE gesetzt. Ein Wert wird aus der Datenbank gelöscht. Der Datensatz bleibt erhalten und die aktuelle Transaktions-ID in EXPIRE gesetzt. Bei einem Update werden zwei Datensätze gehalten. Zuerst wird der Datensatz, analog zum vorherigen Beispiel, als gelöscht markiert, anschliessend wird ein neuer Datensatz erstellt. Die aktuelle Transaktions-ID wird beim alten als EXPIRE und beim neuen als CREATE eingetragen. Abbildung 1: MVCC Verhalten [1] Die Transaktions-ID ist ein Zeitstempel oder eine fortlaufende Transaktions-Nummer: T j mit j = maxarg{ts(t bel ): TS(T bel ) < TS(T i )} (1) bel 4

5 Die MVCC Snapshots kontrollieren welche Datensätze für SQL-Statements sichtbar sind. Ein Snapshot wird je nach Isolationslevel beim Start jedes SQL-Statements (READ COMMITTED) oder beim Transaktionsstart (SERIALIZABLE) erstellt. Die verschiedenen Isolationslevels werden in Kapitel 3.1 genauer beschrieben. Beim Erstellen eines neuen Snapshots werden die höchste Transaktions-ID, die committed wurde, und die aktuell ausgeführten Transaktions-IDs gesammelt. Durch die Information dieser Snapshots weiss das System welche Datensätze für eine Anweisung sichtbar sind. [1] Die Bestimmung mittels Snapshots, ob eine Zeile sichtbar ist, wird mithilfe von Abbildung 2 und Abbildung 3 anhand eines Beispiels erläutert: Ein Snapshot wird erstellt. Die höchste committed Transaktions-ID ist 100, offene Transaktionen sind 25, 50 und 75. Alle anderen Transaktionen wurden committed. Abbildung 2: MVCC Snapshot Zeitleiste [1] Nur CREATE CREATE 30 EXPIRE CREATE 50 EXPIRE CREATE 110 EXPIRE CREATE & EXPIRE CREATE 30 EXPIRE 80 CREATE 30 EXPIRE 75 CREATE 30 EXPIRE 110 Sichtbar Unsichtbar Unsichtbar Unsichtbar Sichtbar Sichtbar Verschiedene Transaktionen schreiben einen neuen Wert in die Datenbank. Der erste Datensatz ist sichtbar, die Transaktion 30 ist weder offen noch grösser als der höchste committed Wert. Der zweite Datensatz ist nicht sichtbar, weil die Transaktion 50 noch offen ist. Der letzte Datensatz ist nicht sichtbar, weil die Transaktion 110 höher ist als der höchste committed Wert. Verschiedene Transaktionen ändern den Datensatz mit CREATE 30. Der erste Datensatz ist unsichtbar weil die Transaktion 80 nicht offen und kleiner als der höchste committed Wert ist. Dieser Datensatz ist somit abgelaufen. Der zweite Datensatz ist noch sichtbar da die Transaktion 75 noch offen ist. Der letzte Datensatz ist sichtbar weil die Transaktion 110 höher als der höchste committed Wert ist. Abbildung 3: MVCC Snapshots Zeilensichtbarkeit [1] 5

6 1.3 Vor- und Nachteile von MVCC Der grosse Vorteil von MVCC ist einerseits, dass Leser nie die Schreiber blockieren und anderseits Schreiber nie die Leser blockieren. Lesen ist dabei jederzeit und ohne zu warten möglich. Der grosse Nachteil ist die sehr speicherintensive Haltung von mehreren Datensatzversionen. Dies benötigt nicht nur einen grösseren Speicherplatz, sondern auch mehr Zeit bei Updates. Ein weiterer Nachteil ist die zwingend notwendige Wartung bzw. das Aufräumen, welches zwischendurch notwendig ist. Als letzte kleine Einschränkung ist zu erwähnen, dass die Transaktions-ID in PostgreSQL nur 32 Bit gross sein kann, das heisst: 4 Milliarden Transaktionen sind möglich, anschliessend beginnt die Zählung wieder bei null. 1.4 Geschwindigkeit von MVCC Da sich MVCC bei PostgreSQL nicht deaktivieren lässt und keine Referenzen im Internet vorhanden sind, wurde eine eigene kleine Testumgebung aufgebaut. Ziel war es, ein Bild davon zu erhalten, wie sich MVCC auf die Lese- und Schreibgeschwindigkeit auswirkt. Microsoft MS SQL bietet eine ähnliche Funktion wie MVCC diese lässt sich jedoch ein- und ausschalten: ALTER DATABASE Datenbankname SET READ_COMMITTED_SNAPSHOT ON; Die folgenden Werte wurden durch das Einfügen bzw. Löschen einfacher Einträge gemessen. Das Einfügen und Löschen wurde bewusst einzeln in einer Schleife durchgeführt um realistischere Werte zu erhalten. Die Testumgebung und die SQL-Skripts sind im Anhang unter 8.2 aufgeführt. Anzahl Einträge INSERT SELECT UPDATE DELETE ON OFF ON OFF ON OFF ON OFF :20 00:30 00:00 00:00 00:18 00:02 00:16 00: :33 04:25 00:04 00:03 03:17 00:09 03:04 03: :40 00:34-01: Tabelle 1: Messresultate MSSQL READ_COMMITED_SNAPSHOT ON/OFF 6

7 Die Grafische Ansicht der erhaltenen Resultate sind in Abbildung 4 bis Abbildung 7 abgebildet. Fehlende Werte wurden hochgerechnet und die Linien wurden interpoliert. Die X-Achse entspricht jeweils der Anzahl Einträge und die Y-Achse entspricht der benötigten Zeit in Sekunden. Abbildung 4: Messresultate INSERT Abbildung 5: Messresultate SELECT Abbildung 6: Messresultate UPDATE Abbildung 7: Messresultate DELETE Die Geschwindigkeitsunterschiede bei INSERT, SELECT und DELETE sind nicht gravierend ausgefallen. Beim UPDATE braucht die Variante mit MVCC rund 20-mal länger. In der Praxis wäre der Unterschied insbesondere beim SELECT erheblich grösser gewesen, da bei gleichzeitigen Schreib- und Leseoperationen die Leser, durch die Aktivierung von MVCC, nie blockiert werden. Denn erst bei parallelen Transaktionen kommt MVCC voll zum Tragen. Je nach Konstellation ist MVCC beim SELECT erheblich schneller. Auf das Testen mit parallelen Transaktionen wurde an dieser Stelle verzichtet, da es sehr viele mögliche Kombinationen gibt und diese von Anwendung zu Anwendung unterschiedlich sind. 7

8 2 MVCC in PostgreSQL 2.1 Grundlagen Jede Transaktion in PostgreSQL erhält eine eigene Transaktions-ID namens xid. Zum Anzeigen der aktuell verwendeten xid s einer Tabelle müssen diese explizit in der SELECT-Query angegeben werden. Ein blosses setzten des * Operators reicht dabei nicht aus. Nachfolgend werden die wichtigsten Befehle für PostgreSQL und MVCC erläutert. Diese sind für das Verständnis dieser Arbeit erforderlich. Auf eine Beschreibung der Grundlegenden SQL- Funktionen wird an dieser Stelle verzichtet und auf entsprechende Fachliteratur verwiesen [3]. Befehl SELECT xmin SELECT xmax SELECT cmin SELECT cmax SELECT txid_current() BEGIN TRANSACTION ROLLBACK TRANSACTION COMMIT TRANSACTION Erläuterung Transaktions-ID für CREATE, wird erstellt bei einem INSERT oder UPDATE. Transaktions-ID für EXPIRE, wird ergänzt bei einen UPDATE oder DELETE. Systembefehle-ID, entspricht der Position in der ein Befehl innerhalb einer Transaktion ausgeführt wurde. Gibt die aktuelle txid zurück. Beginn einer neuen Transaktion. Rückgängig machen aller bisherigen UPDATE und DELETE Befehle innerhalb einer Transaktion. Definitiver Abschluss einer Transaktion. Tabelle 2: Befehle PostgreSQL und MVCC 8

9 Die nachfolgenden Beispiele für INSERT, DELETE, UPDATE und ROLLBACK wurden vom Paper von Momjian [1] abgeleitet und die Testdaten bzw. das entsprechende SQL-Script sind auf seiner Webseite [4] verfügbar. Zur eigentlichen Testtabelle mvcc_demo wird noch eine VIEW mvcc_demo_page0 erstellt, welche die Snapshot Datensätze anzeigt. 2.2 INSERT Beim Einfügen von neuen Objekten wird eine fortlaufende xid zu jedem Objekt erstellt und als xmin eingetragen. Im nachfolgenden Beispiel wurden alle Objekte in einer Transaktion eingefügt und verfügen deshalb über die gleiche xid. Werden diese Objekte jeweils in einer separaten Transaktion eingefügt, hat jedes Objekt eine eigene xid. INSERT INTO mvcc_demo VALUES (10), (20), (30), (40), (50); SELECT xmin, xmax, val FROM mvcc_demo; SELECT * FROM mvcc_demo_page0; Abbildung 8: PostgreSQL INSERT 2.3 DELETE Wird ein Objekt gelöscht, ist es in der normalen Abfrage nicht mehr sichtbar. Auf der rechten Seite ist ersichtlich, dass das Objekt jedoch weiterhin vorhanden ist und lediglich der Wert xmax mit der aktuellen xid der Query eingetragen wurde. DELETE FROM mvcc_demo WHERE val = 20; SELECT xmin, xmax, val FROM mvcc_demo; SELECT * FROM mvcc_demo_page0; Abbildung 9: PostgreSQL DELETE 9

10 2.4 UPDATE Bei einem Update eines Datensatzes wird der alte Wert mit xmax ergänzt und ein neues Objekt mit der aktuellen xid erstellt. Auf der rechten Seite ist ersichtlich, dass bei einem Update ein neues Objekt erstellt wurde. UPDATE mvcc_demo SET val = val + 1 WHERE val = 10; SELECT xmin, xmax, val FROM mvcc_demo; SELECT * FROM mvcc_demo_page0; Abbildung 10: PostgreSQL UPDATE 2.5 ROLLBACK Mit dem Befehl Rollback kann eine laufende Transaktion rückgängig gemacht werden. Dies ist jedoch nur innerhalb einer Transaktion und bevor committed wurde möglich. Auf der rechten Seite ist ersichtlich, dass beim Rollback der Datensatz, wie beim Löschen, markiert wurde. Beim normalen Abrufen der Tabelle ist er jedoch weiterhin vorhanden. BEGIN WORK; DELETE FROM mvcc_demo WHERE val = 30; ROLLBACK WORK; SELECT xmin, xmax, val FROM mvcc_demo; SELECT * FROM mvcc_demo_page0; Abbildung 11: PostgreSQL ROLLBACK 10

11 2.6 Statusmarkierungen Damit ein Rollback wie in Kapitel 2.5 funktioniert, benötigt es ein zusätzliches System, das die Transaktionen mit Statusinformationen markiert. Die Abbildung 12 zeigt das pg_clog von PostgreSQL, dabei wird jede Transaktion xid durch einen Status ergänzt. Es sind drei verschiedene Statusmarkierungen möglich, diese sind: laufend, abgebrochen und committed. Ein Rollback markiert die Transaktions-ID somit als abgebrochen und alle anderen Sessions ignorieren diese Transaktion. Es sind keine weiteren Anpassungen in den Datensätzen oder den Snapshots notwendig. [1] Abbildung 12: PostgreSQL Statusmarkierungen [1] 2.7 Multi-Statement Transaktionen Multi-Statement Transaktionen sind Transaktionen in denen mehrere Befehle ausgeführt werden. Weil jedes Statement seine eigenen Sichtbarkeitsregeln hat, benötigen Multi-Statement Transaktionen ein zusätzliches Tracking. Der Inhalt eines Cursors zum Beispiel muss unverändert bleiben, auch wenn spätere Befehle in derselben Transaktion Datensätze modifizieren. So ein Tracking ist in PostgreSQL durch die Systembefehle-IDs cmin und cmax implementiert, diese werden intern jedoch nur in einer einzelnen Spalte gehalten. Deshalb ist es unmöglich den Status eines Datensatzes, der innerhalb einer Multi-Statement Transaktion erstellt und wieder gelöscht wurde, aufzuzeichnen. In diesem Fall wird in PostgreSQL eine spezielle Combo-Command-ID erzeugt, welche sich auf den lokalen Memory Hash, der den Inhalt der aktuellen cmin und cmax Werte enthält, referenziert. [1] 11

12 Nachfolgend ein Beispiel wie die Ausgabe in PostgreSQL aussieht. Im Paper von Momjian [1] sind viele weitere Beispiele aufgeführt. Der Wert von cmin entspricht der Position innerhalb der Transaktion, an der der INSERT-Befehl ausgeführt wurde. BEGIN WORK; INSERT INTO mvcc_demo VALUES (10); INSERT INTO mvcc_demo VALUES (20); INSERT INTO mvcc_demo VALUES (30); COMMIT WORK; BEGIN WORK; INSERT INTO mvcc_demo VALUES (10), (20), (30); INSERT INTO mvcc_demo VALUES (60), (50), (40); COMMIT WORK; BEGIN WORK; INSERT INTO mvcc_demo VALUES (60); INSERT INTO mvcc_demo VALUES (50); INSERT INTO mvcc_demo VALUES (40); COMMIT WORK; SELECT xmin, cmin, val FROM mvcc_demo; SELECT xmin, cmin, val FROM mvcc_demo; Abbildung 13: PostgreSQL Multi-Statement Transaktion 2.8 Cleanup Da PostgreSQL bei einem UPDATE oder DELETE Befehl einen Datensatz nicht physikalisch löscht, wird jedes Mal eine zweite Version angelegt bzw. die alte als gelöscht markiert. Diese müssen solange beibehalten werden bis andere Transaktionen diese Zeilenversion nicht mehr sehen können. Wird eine Tabelle stark durch UPDATE oder DELETE Befehle ausgelastet, steigt der tote Speicherplatz stark an. Dagegen hilft der Befehl VACUUM, der bei PostgreSQL seit der Einführung von MVCC zur Verfügung steht. Dieser funktioniert wie eine Art Staubsauger und defragmentiert dabei den Heap. Damit man diese Arbeit nicht jedes Mal von Hand erledigen muss, gibt es die Funktion AUTOVACUUM. Des Weiteren führt PostgreSQL beim Aufruf eines SELECT, UPDATE und DELETE Befehls bei Bedarf eine Bereinigung einer einzelnen Heap Page durch. [5], [1] Cleanup Methode Single- Page VACUUM Ausgelöst durch SELECT, UPDATE, DELETE VACUUM, AUTOVACUUM Anwendungsbereich Wiederverwendung Heap Tuples? Non-HOT Item State HOT Item State Clean Indexes? Update FSM? Einzelne Heap Page Ja Tot Unbenutzt Nein Nein Alle potenziellen Heap Pages Ja Unbenutzt Unbenutzt Ja Ja Tabelle 3: PostgreSQL Cleanup Zusammenfassung [1] In Tabelle 3 werden in einer Zusammenfassung die beiden Cleanup Methoden beschrieben. 12

13 Der Aufbau einer Heap Page ist in der Abbildung 14 aufgezeichnet. Die Heap Page besteht aus dem Page Header, Items und Tupel. Der Item Pointer zeigt von einem Item zu einem Tupel. Beim Aufruf von SELECT, UPDATE und DELETE wird nur die Heap Page bereinigt. Durch VACUUM werden zusätzlich auch die Indexe bereinigt, die auf die einzelnen Tupel zeigen. Abbildung 14: PostgreSQL Aufbau Heap Page und Indexe [1] Nachfolgend einen kurzen Überblick über die Befehle für das Aufräumen in PostgreSQL: Befehl TRUNCATE VACUUM AUTOVACUUM VACUUM VERBOSE CREATE INDEX REINDEX TABLE VACUUM FULL Erläuterung Leert eine Tabelle, ist schneller als DELETE da keine Bedingungen definiert werden können. Kann nicht zurückgerollt werden. Manuelles VACUUM Führt ein automatisches VACUUM durch und muss in der Datei PostgreSQLql.conf aktiviert werden: autovacuum = on. Ausgabe des Status der Free Space Map Erstellt ein Index für eine Tabelle Reorganisation des Tabellenindexes Verkleinert die Tabellendatei auf ein Minimum, benötigt jedoch eine exklusive Tabellen-Sperre. Nicht für die tägliche Wartung. Falls jedoch trotzdem notwendig, zuerst VACUUM FULL und anschliessend REINDEX, insbesondere bei älteren PostgreSQL Versionen, notwendig. Tabelle 4: PostgreSQL Cleanup Befehle 13

14 3 Praktischer Teil Ziel dieses Abschnittes war es, einige Anomalien in PostgreSQL zu simulieren. Dafür wurde ein kleines Java Programm geschrieben und versucht, die einzelnen Anomalien zu erzeugen. Die Anomalien über Skew wurden dabei nicht weiter verfolgt. Die technische Umsetzung und Dokumentation des praktischen Teiles sind im Anhang beschrieben. 3.1 Grundlagen Zunächst folgt eine Auflistung der häufigsten und bekanntesten Anomalien und deren Erläuterung. Die theoretischen Ansätze basieren auf dem Dokument von Berenson et al. [2]. Das Isolation Level und die jeweils möglichen Anomalien: Isolation Level Dirty Read Lost Updates Nonrepeatable Read Phantom Read Read uncommitted Möglich Möglich Möglich Möglich Read committed Unmöglich Möglich Möglich Möglich Repeatable read Unmöglich Unmöglich Unmöglich Möglich Serializable Unmöglich Unmöglich Unmöglich Unmöglich Tabelle 5: ANSI SQL Isolation Levels [2] Die Isolation Level und Anomalien bei Systemen mit MVCC: Isolation Level Dirty Read Nonrepeatable Read Phantom Read Lost Updates Read committed Unmöglich Möglich Möglich Möglich Repeatable read Unmöglich Unmöglich Unmöglich Möglich Serializable Unmöglich Unmöglich Unmöglich Unmöglich Tabelle 6: MVCC Isolation Levels [6] In PostgreSQL ist MVCC nicht deaktivierbar. Das Isolation Level kann jedoch folgendermassen angepasst werden: SET TRANSACTION ISOLATION LEVEL ISOLATION LEVEL ; Dieser Befehl muss jeweils am Anfang der Transaktion angegeben werden und kann nach der ersten Query nicht mehr geändert werden. PostgreSQL verwendet den Standardwert READ COM- MITTED. In der Tabelle 6 ist ersichtlich, dass bei Systemen mit MVCC das Isolation Level READ UNCOMMITTED gar nicht notwendig ist. PostgreSQL unterstützt dieses Level jedoch ebenfalls, dabei wird es intern einfach auf den Standardwert gesetzt. [6] 14

15 Durch die Serializable Snapshot Isolation (SSI) Technik, die in PostgreSQL dem Isolation Level SERIALIZABLE entspricht, wird sichergestellt, dass bei jeder möglichen Kombination von seriellen Zugriffen jederzeit das Richtige gemacht wird. Falls notwendig wird automatisch ein Rollback mit einem serialization Fehler durchgeführt. [7] 3.2 Dirty Read Andere Transaktionen können Daten der aktuellen Transaktion lesen, obwohl die Änderungen noch nicht committed wurden Zeitpunkt Transaktion T 1 Transaktion T 2 1 READ x 2 UPDATE x 3 READ x 4 ROLLBACK Tabelle 7: Dirty Read 1. Transaktion T 1 liest einen Datensatz. 2. Transaktion T 2 editiert den Datensatz. 3. T 1 liest den Datensatz bevor T 2 einen COMMIT oder ROLLBACK durchführt. 4. T 2 führt einen ROLLBACK durch. 5. T 1 hat einen Datensatz gelesen der nie committed wurde und so nie wirklich existiert hat. 3.3 Nonrepeatable Read Bei mehrfachen, gleichen Lesezugriffen innerhalb einer Transaktion gibt es unterschiedliche Ergebnisse. Zeitpunkt Transaktion T 1 Transaktion T 2 1 READ x 2 UPDATE x 3 COMMIT 4 READ x Tabelle 8: Nonrepeatable Read 1. Transaktion T 1 liest einen Datensatz. 2. Transaktion T 2 editiert den Datensatz. 3. T 2 führt ein COMMIT durch. 4. T 1 liest den Datensatz erneut. 5. T 1 erhält einen modifizerten Wert oder stellt fest, dass der Datensatz gelöscht wurde. 15

16 3.4 Phantom Read Durch das Einfügen, Ändern oder Löschen gibt es in anderen Transaktionen bei gleichen Bedingungen unterschiedliche Ergebnisse. Zeitpunkt Transaktion T 1 Transaktion T 2 1 READ 2 INSERT 3 COMMIT 4 READ Tabelle 9: Phantom Read 1. Transaktion T 1 liest eine Datensatzmenge, z.b. die Zeilenanzahl. 2. Transaktion T 2 fügt einen neuen Datensatz ein. 3. T 2 führt ein COMMIT durch. 4. T 1 liest die Datensatzmenge erneut. 5. T 1 erhält eine unterschiedliche Datensatzmenge im Vergleich zur ersten Abfrage. 3.5 Lost Update Durch das Aktualisieren des gleichen Datensatzes durch zwei verschiedene Transaktionen geht ein Update verloren. Zeitpunkt Transaktion T 1 Transaktion T 2 1 READ x 2 READ x 3 UPDATE x 4 UPDATE x 5 COMMIT 6 COMMIT Tabelle 10: Lost Update 1. Transaktion T 1 liest einen Datensatz x. 2. Transaktion T 2 liest ebenfalls den Datensatz x. 3. T 1 editiert den Datensatz x. 4. T 2 editiert ebenfalls den Datensatz x. 5. T 1 führt ein COMMIT durch. 6. T 2 führt ein COMMIT durch. 7. Es wird nur die Änderung von T 2 in der Datenbank gespeichert, die Änderung von T 1 geht verloren. 16

17 3.6 Read Skew Durch das Lesen und gleichzeitige Ändern von abhängigen Datensätzen werden inkonsistente Ergebnisse ausgegeben. Zeitpunkt Transaktion T 1 Transaktion T 2 1 READ x 2 UPDATE x, y 3 COMMIT 4 READ y Tabelle 11: Read Skew 1. Transaktion T 1 liest einen Datensatz x. 2. Transaktion T 2 editiert den Datensatz x und einen Datensatz y, diese haben eine Abhängigkeit. 3. T 2 führt ein COMMIT durch. 4. Transaktion T 1 liest den Datensatz y. 5. T 1 sieht einen inkonsistenten Zustand. Beispiel: Eine Tabelle enthält Informationen über Personen. Alle Personeneinträge haben ein Attribut, das angibt, ob eine Person verheiratet ist oder nicht und ein zweites Attribut, das angibt, ob eine Person tot ist oder nicht. Wir nehmen an, dass x und y jeweils Personeneinträge sind und sie miteinander verheiratet sind. Transaktion T 2 markiert x als eine tote Person und Person y als Witwe. Transaktion T 1 hat einen inkonsistenten Zustand gelesen und sieht, dass Person y eine Witwe ist, aber ihr Mann x lebt. [8] 17

18 3.7 Write Skew Durch das gleichzeitige Ändern von gleichen, abhängigen Datensätzen wird die Datenbank inkonsistent und Abhängigkeiten werden verletzt. Zeitpunkt Transaktion T 1 Transaktion T 2 1 READ x, y 2 READ x, y 3 UPDATE x 4 COMMIT 5 UPDATE y 6 COMMIT Tabelle 12: Write Skew 1. Transaktion T 1 liest die Datensätze x und y, diese haben eine Abhängigkeit. 2. Transaktion T 2 liest ebenfalls die Datensätze x und y. 3. T 2 editiert den Datensatz x. 4. T 2 führt ein COMMIT durch. 5. T 1 editiert den Datensatz y. 6. T 1 führt ein COMMIT durch. 7. Die Abhängigkeit zwischen x und y wurde verletzt. Beispiel: Eine Tabelle enthält Informationen über Personen. Alle Personeneinträge haben ein Attribut, das angibt, ob eine Person verheiratet ist oder nicht und ein zweites Attribut, das angibt, ob eine Person tot ist oder nicht. Wir nehmen an, dass x und y jeweils Personeneinträge sind und sie miteinander verheiratet sind. Transaktion T 2 markiert x als eine tote Person und Transaktion T 1 markiert y als Witwe. In diesem Fall ist die Datenbank inkonsistent bis die Transaktion T 1 committed wurde. [8] Die beiden Anomalien Read und Write Skew werden in dieser Arbeit nicht weiter verfolgt. 18

19 4 Fazit und Ausblick MVCC eignet sich hervorragend für sehr viele Lesezugriffe und wenig Schreiboperationen. Durch die Haltung von verschiedenen Versionen eines Datensatzes kann dieser jederzeit gelesen werden. Die Geschwindigkeit ist jedoch, insbesondere beim Aktualisieren, rund 20-mal langsamer. Weitere Nachteile von MVCC sind der erhöhte Speicherplatzbedarf und der Wartungsaufwand. Durch ein geeignetes Wartungskonzept kann die Datenbankgrösse reduziert werden. Das Schreiben der Snapshots auf die physische Harddisk kann auch komplett deaktiviert werden. Dadurch ist PostgreSQL bei einem Serverabsturz jedoch nicht mehr in der Lage, einen konsistenten Zustand der Datenbank zu garantieren. Ob eine relationale Datenbank mit der Funktionalität von MVCC gewählt werden soll, hängt sehr stark von den Anforderungen ab. Die meisten bekannten Hersteller setzten bereits auf dieses Konzept oder bieten es zumindest als Option an. Im praktischen Teil konnten die Anomalien Dirty Read, Nonrepeatable Read, Phantom Read und Lost Update erfolgreich in einem Java Programm umgesetzt werden. Dieses kleine Demo Programm zeigt dabei jeweils auf, wie sich die Werte bei verschiedenen Isolation Levels ändern. Bei der Anomalie Dirty Read konnte kein Fehler generiert werden. Dies ist auf die fehlende Anfälligkeit von MVCC-Systemen auf diese Anomalie zurückzuführen (Tabelle 6) und wurde bereits im Vorfeld so angenommen. In PostgreSQL kann das Isolation Level sehr einfach, am Anfang einer Transaktion angepasst werden. Je höher das Isolation Level gewählt wird, desto weniger Anomalien sind möglich. Dabei werden jedoch auch die Restriktionen erhöht und gleichzeitig schreibende Transaktionen können sich blockieren. Mit dem von PostgreSQL verwendeten Standardwert sind Anomalien zwar möglich. Dieser Wert scheint hinsichtlich Performance und Komplexität gut gewählt und kann bei Bedarf angepasst werden. Das Konzept für MVCC wurde schon 1978 durch Reed [9] bzw durch Bernstein und Goodman [10] entwickelt. Während einige Hersteller wie Oracle diese Technologie bereits 1984 eingeführt haben, dauerte es bei Microsoft bis zum Jahre Bei PostgreSQL ist MVCC seit der Version 6.5 aus dem Jahre 1999 fester Bestandteil. Neue Technologien die das bewährte MVCC in relationalen Datenbanken ablösen scheinen in naher Zukunft keine zu erscheinen. Die aktuellen Trends gehen eher weg von relationalen Datenbanken hin zu Datenbanken, die einen nicht-relationalen Ansatz verfolgen. Einige dieser Datenbanken mit dem sogenannten NoSQL- Ansatz, wie Beispielsweise CouchDB und MongoDB, verwenden jedoch auch wiederum MVCC. 19

20 5 Literaturverzeichnis [1] B. Momjian, MVCC Unmasked, Pennsylvania, [2] H. Berenson, P. Bernstein, J. Gray, J. Melton, E. O'Neil und P. O'Neil, A critique of ANSI SQL isolation levels, Microsoft Corporation, Redmond, [3] K. Douglas und D. Susan, PostgreSQL: a comprehensive guide to building, programming, and administering PostgresSQL databases, SAMS publishing, [4] B. Momjian, SQL Script, [Online]. Available: [Zugriff am 15 März 2014]. [5] B. Helmle, VACUUM FULL, [Online]. Available: [Zugriff am 25 März 2014]. [6] PostgreSQL, Transaction Isolation, [Online]. Available: [Zugriff am 05 Mai 2014]. [7] PostgreSQL, SSI, [Online]. Available: [Zugriff am 29 Mai 2014]. [8] L. Frank, Countermeasures against isolation anomalies, Department of Informatics Copenhagen Business School, Copenhagen, [9] R. David P., Naming and synchronization in a decentralized computer system, Massachusetts Institute of Technology, Cambridge, [10] P. A. Bernstein und N. Goodman, Concurrency control in distributed database systems, (CSUR), ACM Computing Surveys, pp ,

21 6 Abbildungsverzeichnis Abbildung 1: MVCC Verhalten [1]... 4 Abbildung 2: MVCC Snapshot Zeitleiste [1]... 5 Abbildung 3: MVCC Snapshots Zeilensichtbarkeit [1]... 5 Abbildung 4: Messresultate INSERT... 7 Abbildung 5: Messresultate SELECT... 7 Abbildung 6: Messresultate UPDATE... 7 Abbildung 7: Messresultate DELETE... 7 Abbildung 8: PostgreSQL INSERT... 9 Abbildung 9: PostgreSQL DELETE... 9 Abbildung 10: PostgreSQL UPDATE Abbildung 11: PostgreSQL ROLLBACK Abbildung 12: PostgreSQL Statusmarkierungen [1] Abbildung 13: PostgreSQL Multi-Statement Transaktion Abbildung 14: PostgreSQL Aufbau Heap Page und Indexe [1] Tabellenverzeichnis Tabelle 1: Messresultate MSSQL READ_COMMITED_SNAPSHOT ON/OFF... 6 Tabelle 2: Befehle PostgreSQL und MVCC... 8 Tabelle 3: PostgreSQL Cleanup Zusammenfassung [1] Tabelle 4: PostgreSQL Cleanup Befehle Tabelle 5: ANSI SQL Isolation Levels [2] Tabelle 6: MVCC Isolation Levels [6] Tabelle 7: Dirty Read Tabelle 8: Nonrepeatable Read Tabelle 9: Phantom Read Tabelle 10: Lost Update Tabelle 11: Read Skew Tabelle 12: Write Skew

22 8 Anhang 8.1 Planning Milestones Distribution of tasks Kickoff Meeting Delivery task Interim presentation Final practical part Final presentation 22

23 8.2 MSSQL Snapshot Test SQL-Scripts: INSERT 1 ALTER DATABASE test SET READ_COMMITTED_SNAPSHOT ON; 2 CREATE TABLE test (id int IDENTITY(1,1)PRIMARY KEY CLUSTERED, value int); 3 4 integer, integer; begin 11 INSERT INTO test (value) VALUES (1); end SELECT: 1 integer, integer, integer; begin 10 + (SELECT value FROM test WHERE id=1); end UPDATE: 1 integer, integer; begin 8 UPDATE test SET value=2 WHERE id=1; 9 10 end 23

24 DELETE: 1 integer, integer; begin 7 DELETE FROM test WHERE id=@rc; 8 9 end Test Environment: Type Value VM-Player VMware Player Operating System MS Windows 7 64 Bit Service Pack 1 Assigned CPU 4 Processor Cores from Intel 3.50 GHz Assigned RAM 8 GB Assigned HDD 60 GB SATA SQL-Version MS SQL Server 2008 R2 Express 64 Bit with Mgmt 8.3 Documentation Requirements: An installation of PostgreSQLQL on the local host or on a remote system. PostgreSQLQL JDBC Driver Version Library, is included in the JAR-File. Adapting at the firewall on local host or the remote system, PostgreSQL standard port is Editing the Pg_hba.conf File for access outside the local host and restart PostgreSQL. o Example: host all all /24 md5 host all all /24 md5 Creating a new database with name Practices and user/password PostgreSQL. User Guide: Editing the BasicParameters in the DBConnection.java: DB_URL_POSTGRESQL_PREFIX for example: jdbc:postgresqlql:// :5432/practices DB_POSTGRESQL_USER for example: PostgreSQL DB_POSTGRESQL_PASSWORD for example: PostgreSQL 24

25 Run the DBSeminar.java the output in the console looks like this: Start Nonrepeatable Read with READ COMMITTED T1 begin work T1 read the sum -> 330 T2 begin work T2 update a value, sum -> 311 T2 commit T1 read the sum -> 311 T1 commit FAILURE: NonRepeateableRead Start Nonrepeatable Read with REPEATABLE READ T1 begin work T1 read the sum -> 330 T2 begin work T2 update a value, sum -> 311 T2 commit T1 read the sum -> 330 T1 commit OK: No NonRepeateableRead Start LostUpdate with REPEATABLE READ T1 begin work T2 begin work T1 read the first value -> 10 T2 read the first value -> 10 T1 update first value, from 10 to 110 T2 update first value, from 10 to 5 T1 commit T2 commit Update failed OK: No LostUpdate, Value in DB ->

26 The demo makes per default the following tests, you can easy adapt this by editing the code in the DBSeminar.java File. Test Isolationlevel Output DirtyRead 1, READ UNCOMMITTED Always OK (MVCC) NonRepeateableRead1 2, READ COMMITTED FAILURE NonRepeateableRead2 3, REPEATABLE READ OK PhantomRead1 2, READ COMMITTED FAILURE PhantomRead2 3, REPEATABLE READ OK LostUpdate1 2, READ COMMITTED FAILURE LostUpdate2 3, REPEATABLE READ OK, Second Update failed 8.4 Classes Class DBSeminar DBConnection DBHelper Package anomalies Description Main class, starts the anomalies Class for the database connection Helper Class with many methods for accessing table Contains the four anomalies classes 8.5 Source Code This code is hardcoded and only for demonstration purposes, it is therefore not very nice. The source code of the project is also available on the internet under: Class DBSeminar 1 public class DBSeminar { 2 3 private static final String LEVEL1 = "READ UNCOMMITTED"; 4 private static final String LEVEL2 = "READ COMMITTED"; 5 private static final String LEVEL3 = "REPEATABLE READ"; 6 private static final String LEVEL4 = "SERIALIZABLE"; 7 8 /** 9 args the command line arguments 10 */ 11 public static void main(string[] args) throws SQLException { 12 startdirtyread(); //starts the DirtyRead Demo 13 startnonrepeateableread(); //starts the startnonrepeateableread Demo 14 startphantomread(); //starts the PhantomRead Demo 15 startlostupdate(); //starts the LostUpdate Demo 16 } private static void startdirtyread() throws SQLException { 19 //Dirty Read 20 System.out.println("Start DirtyRead with " + LEVEL1); 21 System.out.println(" "); 22 new DirtyRead().dirtyRead(LEVEL1); 23 System.out.println("\n \n"); 24 } private static void startnonrepeateableread() throws SQLException { 26

27 27 //Nonrepeatable Read 1 28 System.out.println("Start Nonrepeatable Read with " + LEVEL2); 29 System.out.println(" "); 30 new NonRepeateableRead().nonRepeateableRead(LEVEL2); 31 System.out.println("\n \n"); //Nonrepeatable Read 2 34 System.out.println("Start Nonrepeatable Read with " + LEVEL3); 35 System.out.println(" "); 36 new NonRepeateableRead().nonRepeateableRead(LEVEL3); 37 System.out.println("\n \n"); 38 } private static void startphantomread() throws SQLException { 41 //PhantomRead 1 42 System.out.println("Start PhantomRead with " + LEVEL2); 43 System.out.println(" "); 44 new PhantomRead().phantomRead(LEVEL2); 45 System.out.println("\n \n"); //PhantomRead 2 48 System.out.println("Start PhantomRead with " + LEVEL3); 49 System.out.println(" "); 50 new PhantomRead().phantomRead(LEVEL3); 51 System.out.println("\n \n"); 52 } private static void startlostupdate() throws SQLException { 55 //LostUpdate 1 56 System.out.println("Start LostUpdate with " + LEVEL2); 57 System.out.println(" "); 58 new LostUpdate().lostUpdate(LEVEL2); 59 System.out.println("\n \n"); //LostUpdate 2 62 System.out.println("Start LostUpdate with " + LEVEL3); 63 System.out.println(" "); 64 new LostUpdate().lostUpdate(LEVEL3); 65 System.out.println("\n \n"); 66 } 67 } Class DBConnection 1 public class DBConnection { 2 3 private static final String DB_POSTGRESQL_DRIVER = "org.postgresqlql.driver"; //PostgreSQL Driver 4 private static final String DB_URL_POSTGRESQL_PREFIX = "jdbc:postgresqlql:// :5432/practices"; //URL to the PostgreSQL Server (Localhost or Remote) 5 private static final String DB_POSTGRESQL_USER = "PostgreSQL"; //DB username 6 private static final String DB_POSTGRESQL_PASSWORD = "PostgreSQL"; //DB password 7 private static final boolean LOG_ON = false; //Acitvates the extended Logging 8 9 public Connection connect() { //Extended log-output if enabled 12 if(log_on) { DriverManager.setLogWriter( new PrintWriter( System.out ) ); } //Verify that the PostgreSQL driver ist inlucded in the library 15 try { 16 Class.forName(DB_POSTGRESQL_DRIVER); 17 } catch (ClassNotFoundException e) { 18 System.out.println("PostgreSQLQL JDBC Driver not found, include in your library"); 19 } Connection connection = null; //Connecetion to the database 24 try { 25 connection = DriverManager.getConnection(DB_URL_POSTGRESQL_PREFIX, 27

28 DB_POSTGRESQL_USER, DB_POSTGRESQL_PASSWORD); 26 } catch (SQLException e) { 27 System.out.println("Connection failed, check Firewall, Adress, Port, Username and Password"); 28 } if (connection!= null) { 31 //System.out.println("Connected to the database"); 32 } else { 33 System.out.println("Connection failed"); 34 } return connection; 37 } 38 } Class DBHelper 1 public class DBHelper { 2 3 private static final String TABLENAME = "testdata"; //name of the created table 4 5 private static final String QUERYCREATETABLE = "DROP TABLE IF EXISTS " + TABLENAME + ";\n" 6 + "CREATE TABLE " + TABLENAME + " (id INT, value INT);\n" 7 + "INSERT INTO " + TABLENAME + " (id, value) VALUES (1,10), (2,20), (3,100), (4,200);\n"; 8 9 //drop the old table and create a new table 10 public static void createtable(connection connection) { 11 PreparedStatement ps = null; 12 try { 13 ps = connection.preparestatement(querycreatetable); 14 ps.executeupdate(); 15 ps.close(); 16 } catch (SQLException ex) { 17 System.out.println("Table creation failed"); 18 } 19 } //begin the transaction 22 public static void begintransaction(connection connection) { 23 try { 24 connection.createstatement().executeupdate("begin TRANSACTION;"); 25 } catch (SQLException ex) { 26 System.out.println("Begin transaction failed"); 27 } 28 } //commits a transaction 31 public static void committransaction(connection connection) { 32 try { 33 connection.createstatement().executeupdate("commit TRANSACTION;"); 34 } catch (SQLException ex) { 35 System.out.println("Commit transaction failed"); 36 } 37 } //makes a rollback of the transaction 40 public static void rollbacktransaction(connection connection) { 41 try { 42 connection.createstatement().executeupdate("rollback TRANSACTION;"); 43 } catch (SQLException ex) { 44 System.out.println("Rollback transaction failed"); 45 } 46 } //sets the isolation level 49 public static void setisolationlevel(connection connection, String isolationlevel) { 50 try { 51 connection.createstatement().executeupdate("set TRANSACTION ISOLATION LEVEL " + isolationlevel + ";"); 52 } catch (SQLException ex) { 28

29 53 System.out.println("Set Isolation Level failed"); 54 } 55 } //inserts a new value in the table 58 public static void insertvalue(connection connection) { 59 Statement st = null; 60 try { 61 st = connection.createstatement(); 62 st.executeupdate("insert INTO " + TABLENAME + " (id, value) VALUES (5, 30);"); 63 st.close(); 64 } catch (SQLException ex) { 65 System.out.println("Insert failed"); 66 } 67 } //updates a value in the table 70 public static void updatevalue(connection connection) { 71 Statement st = null; 72 try { 73 st = connection.createstatement(); 74 st.executeupdate("update " + TABLENAME + " SET value=1 WHERE id=2;"); 75 st.close(); 76 } catch (SQLException ex) { 77 System.out.println("Update failed"); 78 } 79 } //updates the first value in the table 82 public static void updatefirst(connection connection, int value) { 83 Statement st = null; 84 try { 85 st = connection.createstatement(); 86 st.executeupdate("update " + TABLENAME + " SET value=" + value +" WHERE id=1;"); 87 st.close(); 88 } catch (SQLException ex) { 89 System.out.println("Update failed"); 90 } 91 } //deletes a value from the table 94 public static void deletevalue(connection connection) { 95 Statement st = null; 96 try { 97 st = connection.createstatement(); 98 st.executeupdate("delete FROM " + TABLENAME + " WHERE id=1;"); 99 st.close(); 100 } catch (SQLException ex) { 101 System.out.println("Delete failed"); 102 } 103 } //gets the sum over all values in the table 106 public static int getsum(connection connection) { 107 Statement st = null; 108 ResultSet rs = null; 109 int sum = 0; 110 try { 111 st = connection.createstatement(); 112 rs = st.executequery("select SUM(value) FROM " + TABLENAME + ";"); 113 rs.next(); 114 sum = rs.getint(1); 115 rs.close(); 116 st.close(); 117 } catch (SQLException ex) { 118 System.out.println("Failed to calculate the sum"); 119 } 120 return sum; 121 } //gets the first value from the table 124 public static int getfirst(connection connection) { 125 Statement st = null; 29

30 126 ResultSet rs = null; 127 int first = 0; 128 try { 129 st = connection.createstatement(); 130 rs = st.executequery("select value FROM " + TABLENAME + " WHERE id=1;"); 131 rs.next(); 132 first = rs.getint(1); 133 rs.close(); 134 st.close(); 135 } catch (SQLException ex) { 136 System.out.println("Failed to get first value"); 137 } 138 return first; 139 } //select table gives the whole table 142 private static final String QUERYSELECTTABLE = "SELECT id, value FROM " + TABLENAME + ";"; 143 public static void selecttable(connection connection) { 144 Statement st = null; 145 ResultSet rs = null; 146 ResultSetMetaData rsmd = null; 147 int spalten; try { 150 st = connection.createstatement(); 151 rs = st.executequery(queryselecttable); 152 rsmd = rs.getmetadata(); 153 spalten = rsmd.getcolumncount(); while (rs.next()) { 156 int i = 1; 157 while (i < spalten + 1) { 158 System.out.print(rs.getString(i) + " "); 159 i++; 160 } 161 System.out.print("\n"); 162 } rs.close(); 165 st.close(); 166 } catch (SQLException ex) { 167 System.out.println("Select failed"); 168 } 169 } 170 } Class DirtyRead 1 public class DirtyRead { 2 3 public void dirtyread(string isolationlevel) throws SQLException { 4 //Dirty Read 5 Connection connection = new DBConnection().connect(); 6 DBHelper.createTable(connection); 7 connection.close(); 8 9 //T1 begin 10 System.out.println("T1 begin work"); 11 Connection T1 = new DBConnection().connect(); 12 DBHelper.beginTransaction(T1); 13 DBHelper.setIsolationLevel(T1, isolationlevel); //T1 read 16 int sum1 = DBHelper.getSum(T1); 17 System.out.println("T1 read the sum -> " + sum1); //T2 begin 20 System.out.println(" T2 begin work"); 21 Connection T2 = new DBConnection().connect(); 22 DBHelper.beginTransaction(T2); 23 DBHelper.setIsolationLevel(T2, isolationlevel); 24 30

31 25 //T2 update 26 System.out.print(" T2 update a value, sum -> "); 27 DBHelper.updateValue(T2); 28 System.out.println(DBHelper.getSum(T2)); //T1 read 31 int sum2 = DBHelper.getSum(T1); 32 System.out.println("T1 read the sum -> " + sum2); 33 T1.close(); //T2 rollback 36 System.out.println(" T2 makes a rollback"); 37 DBHelper.rollbackTransaction(T2); 38 T2.close(); //Check 41 if (sum1 == sum2) { 42 System.out.println("OK: No Dirty Read"); 43 } else { 44 System.out.println("FAILURE: Dirty Read"); 45 } 46 } 47 } Class NonRepeateableRead 1 public class NonRepeateableRead { 2 3 public void nonrepeateableread(string isolationlevel) throws SQLException { 4 //Nonrepeatable Read 5 Connection connection = new DBConnection().connect(); 6 DBHelper.createTable(connection); 7 connection.close(); 8 9 //T1 begin 10 System.out.println("T1 begin work"); 11 Connection T1 = new DBConnection().connect(); 12 DBHelper.beginTransaction(T1); 13 DBHelper.setIsolationLevel(T1, isolationlevel); //T1 read 16 int sum1 = DBHelper.getSum(T1); 17 System.out.println("T1 read the sum -> " + sum1); //T2 begin 20 System.out.println(" T2 begin work"); 21 Connection T2 = new DBConnection().connect(); 22 DBHelper.beginTransaction(T2); 23 DBHelper.setIsolationLevel(T2, isolationlevel); //T2 update 26 System.out.print(" T2 update a value, sum -> "); 27 DBHelper.updateValue(T2); 28 System.out.println(DBHelper.getSum(T2)); //T2 commit 31 System.out.println(" T2 commit"); 32 DBHelper.commitTransaction(T2); 33 T2.close(); //T1 read 36 int sum2 = DBHelper.getSum(T1); 37 System.out.println("T1 read the sum -> " + sum2); //T1 commit 40 System.out.println("T1 commit"); 41 DBHelper.commitTransaction(T1); 42 T1.close(); //Check 45 if (sum1 == sum2) { 46 System.out.println("OK: No NonRepeateableRead"); 31

32 47 } else { 48 System.out.println("FAILURE: NonRepeateableRead"); 49 } 50 } 51 } Class PhantomRead 1 public class PhantomRead { 2 3 public void phantomread(string isolationlevel) throws SQLException { 4 //PhantomRead 5 Connection connection = new DBConnection().connect(); 6 DBHelper.createTable(connection); 7 connection.close(); 8 9 //T1 begin 10 System.out.println("T1 begin work"); 11 Connection T1 = new DBConnection().connect(); 12 DBHelper.beginTransaction(T1); 13 DBHelper.setIsolationLevel(T1, isolationlevel); //T1 read 16 int sum1 = DBHelper.getSum(T1); 17 System.out.println("T1 read the sum -> " + sum1); //T2 begin 20 System.out.println(" T2 begin work"); 21 Connection T2 = new DBConnection().connect(); 22 DBHelper.beginTransaction(T2); 23 DBHelper.setIsolationLevel(T2, isolationlevel); //T2 insert 26 System.out.print(" T2 insert a value, sum -> "); 27 DBHelper.insertValue(T2); 28 System.out.println(DBHelper.getSum(T2)); //T2 commit 31 System.out.println(" T2 commit"); 32 DBHelper.commitTransaction(T2); 33 T2.close(); //T1 read 36 int sum2 = DBHelper.getSum(T1); 37 System.out.println("T1 read the sum -> " + sum2); //T1 commit 40 System.out.println("T1 commit"); 41 DBHelper.commitTransaction(T1); 42 T1.close(); //Check 45 if (sum1 == sum2) { 46 System.out.println("OK: No PhantomRead"); 47 } else { 48 System.out.println("FAILURE: PhantomRead"); 49 } 50 } 51 } Class LostUpdate 1 public class LostUpdate { 2 3 private Connection T1 = new DBConnection().connect(); 4 private Connection T2 = new DBConnection().connect(); 5 6 public void lostupdate(string isolationlevel) throws SQLException { 7 //LostUpdate 8 Connection connection = new DBConnection().connect(); 9 DBHelper.createTable(connection); 10 connection.close(); 32

33 11 12 //T1 begin 13 System.out.println("T1 begin work"); 14 DBHelper.beginTransaction(T1); 15 DBHelper.setIsolationLevel(T1, isolationlevel); //T2 begin 18 System.out.println(" T2 begin work"); 19 DBHelper.beginTransaction(T2); 20 DBHelper.setIsolationLevel(T2, isolationlevel); //T1 read 23 System.out.print("T1 read the first value -> "); 24 int before1 = DBHelper.getFirst(T1); 25 System.out.println(before1); //T2 read 28 System.out.print(" T2 read the first value -> "); 29 int before2 = DBHelper.getFirst(T1); 30 System.out.println(before2); //T1 update 33 int after1 = before ; 34 System.out.println("T1 update first value, from " + before1 + " to " + after1); 35 DBHelper.updateFirst(T1, after1); //T2 update 38 final int after2 = before2-5; 39 System.out.println(" T2 update first value, from " + before2 + " to " + after2); 40 //open the second update in a new Thread for waiting of the commit from T1 41 new Thread() { 42 public void run() { 43 try { 44 DBHelper.updateFirst(T2, after2); 45 } catch (Exception ex) { 46 System.out.println("Failure in Thread"); 47 } 48 } 49 }.start(); 50 //sleep for two seconds to be sure that the thread is started 51 try { 52 Thread.sleep(2000); 53 } catch (InterruptedException e) { 54 } //T1 commit 57 System.out.println("T1 commit"); 58 DBHelper.commitTransaction(T1); //T2 commit 61 System.out.println(" T2 commit"); 62 DBHelper.commitTransaction(T2); //check 65 int dbvalueafter = DBHelper.getFirst(T1); 66 if (dbvalueafter == after1) { 67 System.out.println("OK: No LostUpdate, Value in DB -> " + dbvalueafter); 68 } else { 69 System.out.println("FAILURE: LostUpdate, Value in DB -> " + dbvalueafter); 70 } T1.close(); 73 T2.close(); 74 } 75 } 33