{"id":469,"date":"2011-01-12T18:34:18","date_gmt":"2011-01-12T17:34:18","guid":{"rendered":"https:\/\/d-mueller.de\/blog\/?p=469"},"modified":"2016-01-12T00:00:55","modified_gmt":"2016-01-11T23:00:55","slug":"datenbank-transaktionen-von-akademischer-seite-behind-the-scenes","status":"publish","type":"post","link":"https:\/\/d-mueller.de\/blog\/datenbank-transaktionen-von-akademischer-seite-behind-the-scenes\/","title":{"rendered":"Datenbank-Transaktionen von akademischer Seite: Behind the Scenes"},"content":{"rendered":"

Disclaimer<\/h2>\n

An diejenigen mit ordentlichen Vorkenntnissen auf dem Gebiet der Transaktionen: Bitte nicht Abschrecken lassen. Es geht nach der kurzgehaltenen Einf\u00fchrung noch ordentlich in die Tiefe.<\/p>\n

Was sind Transaktionen<\/h2>\n

Nach Definition ist eine Transaktion eine logische Arbeitseinheit, die entweder ganz oder garnicht<\/b> durchgef\u00fchrt wird. Bei einem Fehler wird die Datenbank also in den Zustand vor<\/b> Ausf\u00fchrung der Transaktion versetzt, als ob nie etwas geschehen w\u00e4re.<\/p>\n

\nBeispiel<\/b>: Wo k\u00f6nnte man Transaktionen mehr ben\u00f6tigen als auf einem Gebiet, auf dem Fehler richtig weh tun? Die Bankenwelt! Man stelle sich folgendes ultrasimples Datenmodell vor:<\/p>\n

\r\nCREATE TABLE  `konto` (\r\n`kontonr` INT NOT NULL PRIMARY KEY ,\r\n`betrag` INT NOT NULL DEFAULT  '0',\r\n`kundenid` INT NOT NULL\r\n) ENGINE = INNODB;\r\n\r\nCREATE TABLE  `ueberweisung` (\r\n`ueberweisungsid` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,\r\n`from_kontonr` INT NOT NULL ,\r\n`to_kontonr` INT NOT NULL ,\r\n`betrag` INT NOT NULL\r\n) ENGINE = INNODB;\r\n<\/pre>\n
Man beachte InnoDB als Engine, da MyISAM keine Transaktionen unterst\u00fctzt. Folgendes Codebeispiel (bitte wirklich genauer anschauen & verstehen, ist wichtig f\u00fcr den Ablauf):<\/p>\n
\r\n$conn = new PDO("mysql:host=localhost;dbname=konto", "root", "");\r\n$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);\r\n\r\ntry\r\n{\r\n\t$conn->exec("START TRANSACTION");\r\n\t\r\n\t$conn->exec('INSERT INTO ueberweisung (from_kontonr,to_kontonr,betrag) VALUES (1,2,400)');\r\n\t$conn->exec("UPDATE konto SET betrag = betrag - 400 WHERE kontonr = 1");\r\n\t\r\n\t\/\/etwas geht schief...\r\n\t$conn->exec("Korruptes SQL Statement, das einen Datenbankfehler symbolisiert");\r\n\t\r\n\t$conn->exec("UPDATE konto SET betrag = betrag + 400 WHERE kontonr = 2");\r\n\t\r\n\t$conn->exec("COMMIT"); \/\/Transaktion abgeschlossen\r\n}\r\ncatch (Exception $e)\r\n{\r\n\tprint "Error: ".$e->getMessage();\r\n\t$conn->exec("ROLLBACK"); \/\/Zur\u00fcck zum Zustand vor "START TRANSACTION"\r\n}\r\n<\/pre>\n
Hierbei verwende ich bewusst die expliziten SQL-Kommandos START TRANSACTION<\/b>, COMMIT<\/b> und ROLLBACK<\/b> und nicht das in PDO bereits verzahnte Transaktions-Handling. Dazu sp\u00e4ter mehr. Ohne Transaktionen w\u00fcrde in obigem Fall das Geld von erstem Konto abgebucht werden, ohne jemals auf dem Zielkonto anzukommen. Man stelle sich anstelle von meinem korrupten SQL-Statement einen beliebigen Fehler vor (Stromausfall, Headcrash, …).<\/p>\n
Okay, haben wir den Sinn von Transaktionen gekl\u00e4rt.<\/b>\n<\/p>\n
Savepoints<\/h2>\n
Das Ganze l\u00e4sst sich nun noch etwas feingranularer gestalten:<\/p>\n
\r\n$conn->exec("START TRANSACTION");\r\n\r\ntry\r\n{\r\n\t$conn->exec('INSERT INTO ueberweisung (from_kontonr,to_kontonr,betrag) VALUES (1,2,400)');\r\n\t$conn->exec("UPDATE konto SET betrag = betrag - 400 WHERE kontonr = 1");\r\n\t$conn->exec("UPDATE konto SET betrag = betrag + 400 WHERE kontonr = 2");\r\n\t$conn->exec("SAVEPOINT ueberweisung1");\r\n}\r\ncatch (Exception $e)\r\n{\r\n\tprint "Error in \u00dcberweisung 1: ".$e->getMessage();\r\n\t$conn->exec("ROLLBACK");\r\n}\r\n\r\ntry\r\n{\r\n\t$conn->exec('INSERT INTO ueberweisung (from_kontonr,to_kontonr,betrag) VALUES (3,4,3600)');\r\n\t$conn->exec("UPDATE konto SET betrag = betrag - 3600 WHERE kontonr = 3");\r\n\t\r\n\t$conn->exec("Hier passiert was bl\u00f6des");\r\n\t\r\n\t$conn->exec("UPDATE konto SET betrag = betrag + 3600 WHERE kontonr = 4");\r\n}\r\ncatch (Exception $e)\r\n{\r\n\tprint "Error in \u00dcberweisung 2: ".$e->getMessage();\r\n\t$conn->exec("ROLLBACK TO ueberweisung1");\r\n}\r\n\r\n$conn->exec("COMMIT");\r\n<\/pre>\n
Nach der erfolgreichen \u00dcberweisung im ersten Block wird ein Savepoint<\/a> definiert (SAVEPOINT ueberweisung1<\/b>). Der Fehler in der zweiten \u00dcberweisung f\u00fchrt nun nicht zu einem kompletten Rollback, die erste \u00dcberweisung bleibt bestehen. Nat\u00fcrlich w\u00fcrde man in der Praxis jede \u00dcberweisung in eine eigene Transaktion verpacken, dann w\u00fcrde mein Beispiel aber nicht mehr klappen ;).<\/p>\n
Die Probleme von Transaktionen<\/h2>\n
Okay, bis hierher war ja alles cool. Nun stelle man sich aber mal Mehrbenutzerbetrieb vor. Verschiedene Transaktionen laufen parallel<\/b> auf der Datenbank und operieren mit den gleichen Daten. Dazu ist hier exemplarisch ein Vorgang so dargestellt, wie er Datenbank-intern ablaufen k\u00f6nnte. Herr M\u00fcller mit Kontonummer 1 kauft sich ein neues Fahrrad f\u00fcr 400 Euro und bekommt parallel in der selben Mikrosekunde sein Gehalt von 2000\u20ac \u00fcberwiesen<\/p>\n
\n\"\"<\/a>\n<\/p>\n
Schlecht, oder?<\/b> Wenn der Betriebssystem-Scheduler fies ist und genau so die Prozesse wechselt, ist das Gehalt weg. Aber die Datenbanksystem-Entwickler sind ja nicht auf der Wurstpelle dahergeschwommen. Daher:<\/p>\n
ACID to the rescue<\/h2>\n
\nACID steht f\u00fcr A<\/b>tomicity, C<\/b>onsistency, I<\/b>solation und D<\/b>urability.\n<\/p>\n