Transaktionen

vorige Präsentation: Änderungen an der Datenbank | zurück zum Buch-Kapitel [esc] | Nächste Präsentation Transaktionen und PHP

Transaktionen auf Ebene von SQL, hier am Beispiel von Postgres gezeigt.

ACID

Bei der Ausführung von Transaktionen muss das Transaktionssystem die ACID-Eigenschaften garantieren:

Atomarität bedeutet: Eine Transaktion wird entweder ganz oder gar nicht ausgeführt. Transaktionen sind also „unteilbar“. Wenn eine atomare Transaktion abgebrochen wird, ist das System unverändert.

Konsistenz bedeutet: Nach Ausführung der Transaktion muss der Datenbestand in einer konsistenten Form sein, wenn er es bereits zu Beginn der Transaktion war.

Isolation bedeutet: Bei gleichzeitiger Ausführung mehrerer Transaktionen dürfen sich diese nicht gegenseitig beeinflussen.

Dauerhaftigkeit bedeutete Die Auswirkungen einer Transaktion müssen im Datenbestand dauerhaft bestehen bleiben. Die Effekte von Transaktionen dürfen also nicht „mit der Zeit verblassen“ oder „aus Versehen verloren gehen“.

commit

Sql Code Beispiel für eine Transaktion in POSTGRES, die zwei Einfüge-Operationen zusammenfasst

BEGIN;
INSERT INTO staff (id, first, last) 
  VALUES (42, 'Alyssa', 'Hacker');
INSERT INTO salarychange (id, amount, changedate) 
  VALUES (42, 50000, NOW());
COMMIT;

rollback

Sql Code Beispiel für eine Transaktion in Postgres, die zurück-gerollt wird

BEGIN;
INSERT INTO staff (id, first, last) 
  VALUES (42, 'Alyssa', 'Hacker');
INSERT INTO salarychange (id, amount, changedate) 
  VALUES (42, 50000, NOW());
ROLLBACK;
-- nichts ist passiert!

Tipp: Nicht auf Input warten

Schlecht:

BEGIN;
-- warte auf input ... beliebig lagen
COMMIT;

Probleme ohne Transaktionen

Bei Datenbanken können durch mangelnde Transaktionsisolation die folgenden Anomalie auftreten:

Weniger gute Transaktionen

Mit SET TRANSACTION ISOLATION LEVEL ... kann eine weniger gut Version von Transaktionen aktiviert werden. Die möglichen Werte sind (laut Postgres):

Read Committed Dieses Isolationslevel setzt für die gesamte Transaktion Schreibsperren auf Objekten, die verändert werden sollen, setzt Lesesperren aber nur kurzzeitig beim tatsächlichen Lesen der Daten ein. Daher können Non-Repeatable Read und Phantom Read auftreten, wenn während wiederholten Leseoperationen auf dieselben Daten, zwischen der ersten und der zweiten Leseoperation, eine Schreiboperation einer anderen Transaktion die Daten verändert und committed.

Repeatable Read Bei dieser Isolationsebene ist sichergestellt, dass wiederholte Leseoperationen mit den gleichen Parametern auch dieselben Ergebnisse haben. Sowohl bei Lese- als auch bei Schreiboperationen werden für die gesamte Dauer der Transaktion Sperren gesetzt. Dies führt dazu, dass bis auf Phantom Reads keine Anomalien auftreten können.

Serializable Die höchste Isolationsebene garantiert, dass die Wirkung parallel ablaufender Transaktionen exakt dieselbe ist wie sie die entsprechenden Transaktionen zeigen würden, liefen sie nacheinander in Folge ab

Vertiefende Informationen

Transaktionen

vorige Präsentation: Änderungen an der Datenbank | zurück zum Buch-Kapitel [esc] | Nächste Präsentation Transaktionen und PHP

/

#