2.2 ACID-Transaktionseigenschaften

 Das klassische Transaktionskonzept, das aus dem Bereich der Datenbanken stammt, basiert auf den ACID-Eigenschaften (siehe [Gray 1978] und [Gray, Reuter 1992]). Diese Eigenschaften haben sich zur Grundlage für die Betrachtung von Transaktionen entwickelt und bieten somit ein Vergleichskriterium für verschiedene erweiterte Transaktionskonzepte. ACID steht dabei für die folgenden vier Eigenschaften:

Atomicity:

Fehler-Atomarität oder Alles-oder-Nichts-Eigenschaft. Es werden entweder alle Zustandsänderungen einer Transaktion an den Objekten durchgeführt oder gar keine. Bei einem fehlerhaften Ende, also einem Abbruch der Transaktion, müssen alle Objekte deshalb einen Zustand bekommen, der so aussieht, als habe die Transaktion nie begonnen.

Consistency:

Konsistenz. Von Transaktionen wird gefordert, daß sie, wenn sie alleine abliefen, nur konsistente Zustandsänderungen durchführen. Es liegt in der Verantwortung des Applikationsprogrammierers, daß die Transaktion nur Objektzustände erzeugt, die nach Applikationssemantik zulässig sind.

Isolation:

Isolierte Transaktionen dürfen von anderen nebenläufigen Transaktionen und deren möglichen Abbrüchen nicht beeinflußt werden. Dies wird durchgesetzt, indem alle Änderungen einer Transaktion erst bei ihrem erfolgreichen Ende für die anderen Transaktionen sichtbar gemacht werden.

Durability:

Permanenz des Effekts. Zustandsänderungen von erfolgreich beendeten Transaktionen bleiben permanent, auch wenn nachher Systemfehler wie zum Beispiel Rechnerausfälle auftreten.

Diese vier Eigenschaften lassen sich in Bezug auf eine Transaktionsverwaltung folgendermaßen klassifizieren:

Konsistenz ist eine Anforderung an die Applikation und nicht an die Transaktionsverwaltung. Bei den weiteren Betrachtungen wird sie deshalb vorausgesetzt und nicht mehr betrachtet.

Fehler-Atomarität und Permanenz betreffen die Fehlerbehandlung. Zur Durchsetzung dieser beiden Eigenschaften können Transaktionen bei ihrem Ende in zwei verschiedene Zustände übergehen: Im Zustand abgebrochen wurden aufgrund der Fehler-Atomarität keine Änderungen der Transaktion durchgeführt, während der Zustand committed besagt, daß alle Änderungen durchgeführt wurden und auch nicht mehr durch Systemfehler verloren gehen können.

Die Isolation schließlich betrifft die Nebenläufigkeitskontrolle, hat aber bei Transaktionen auch Einfluß auf die Art der Fehlerbehandlung: Das klassische Transaktionskonzept geht davon aus, daß bei einem Transaktionsabbruch genau die Objektänderungen betroffen sind, die von der abbrechenden Transaktion durchgeführt wurden. Fehler-Atomarität kann daher garantiert werden, indem bei einem Abbruch alle von dieser Transaktion geänderten Objekte auf den Wert zurückgesetzt werden, den diese zu Beginn der Transaktion hatten. Andere Objekte müssen nicht betrachtet werden. Diese Annahme ist aber nur dann gültig, wenn Transaktionen isoliert ablaufen, da sonst die später zurückgesetzten Objektänderungen bereits von anderen Transaktionen gelesen und zu Berechnungen benutzt worden sein könnten. Erst bei dynamischen Aktionen gibt es eine vollständige Trennung von Fehlerbehandlung und Nebenläufigkeitskontrolle. Hier werden Atomarität und Permanenz garantiert, ohne daß Isolation gefordert wird.

Unter dem Gesichtspunkt der Nebenläufigkeitskontrolle stellt die Isolationseigenschaft eine verschärfte Form der Serialisierbarkeit dar. Diese grundlegende Eigenschaft besagt, daß nebenläufige Transaktionen den gleichen Effekt haben müssen, wie in einem Ablauf, in dem sie seriell nacheinander ausgeführt werden. Dadurch verhindert Serialisierbarkeit gegenseitige Einflüsse von Transaktionen und garantiert im fehlerfreien Fall die Unabhängigkeit der einzelnen Transaktionen, selbst wenn sie nebenläufig auftreten. Im Gegensatz zur Isolation, die die Unabhängigkeit der Transaktionen auch im Fehlerfall garantiert, fordert die Serialisierbarkeit nicht, daß Objektänderungen erst bei Ende einer Transaktion sichtbar gemacht werden dürfen. Beispielsweise erlaubt das bei geschachtelten dynamischen Aktionen benutzte nicht-strikte Zwei-Phasen-Sperrprotokoll (siehe Abschnitt 2.6.2) bei garantierter Serialisierbarkeit, Objektänderungen frühzeitig sichtbar zu machen.

Serialisierbarkeit erlaubt einen Ablauf der Transaktionen, der frei von sogenannten Nebenläufigkeitsanomalien ist (siehe [Gray, Reuter 1992]). Diese klassifizieren solche unerwünschten Effekte, in denen eine Berechnung den Ausgang einer anderen dadurch beeinflußt, daß sie nebenläufig auftritt und dieselben Objekte benutzt. Da die Berechnungen in der Regel nichts von der Existenz anderer Berechnungen wissen und diese daher auch nicht berücksichtigen, würden Nebenläufigkeitsanomalien oft zu unvorhersehbaren Störungen der Berechnung führen.

Allerdings ist es auch öfters unerwünscht, gegenseitige Einflüsse durch die erzwungene Serialisierbarkeit systemseitig auszuschließen, da so auch jede Art von Kooperation von Transaktionen verhindert wird. Oft heben deshalb erweiterte Transaktionskonzepte zumindest teilweise die Serialisierbarkeit auf. Die dabei auftretenden Effekte sollen hier genauer untersucht werden.

Nebenläufige (erweiterte) Transaktionen können sich gegenseitig beeinflussen, indem sie zumindest teilweise dieselben Objekte benutzen. Dabei können Zwischenergebnisse der einzelnen Transaktionen zu Argumenten der jeweils anderen Transaktion werden. Abbildung 2.1 zeigt ein dafür typisches Szenario.

  

Abbildung: sich beeinflussende nebenläufige Transaktionen

Je nach Kontext ist eine solche Beeinflussung unterschiedlich zu bewerten: Zum einen könnte sie gewollt sein. In diesem Beispiel könnte die Transaktion T₁ in dem Objekt o₁ ein Zwischenergebnis für Transaktion T₂ ablegen. Diese liest es, führt weitere Berechnungen durch und speichert ihr Ergebnis wieder in o₁, um es T₁ zur Verfügung zu stellen. Der gleiche Ablauf kann aber auch eine ganz andere Bedeutung haben: Die Transaktionen T₁ und T₂ sind unabhängig voneinander und arbeiten nur zufällig gleichzeitig auf demselben Objekt. T₁ besteht dabei aus zwei Modulen, die jeweils den Wert von Objekt o₁ lesen, verändern und wieder zurückschreiben. Transaktion T₁ geht dabei davon aus, daß das zweite Modul aus o₁ den Wert liest, den das erste Modul vorher geschrieben hat. Transaktion T₂ würde durch die zwischenzeitliche Veränderung von o₁ das Ergebnis von T₁ verfälschen.

Dieses Beispiel macht deutlich, daß es ausschließlich von der Anwendungssemantik abhängt, ob eine gegenseitige Beeinflussung gewollt und damit zulässig ist, oder ob sie verhindert werden sollte. Diese Beeinflussungen werden in einer Transaktionsverwaltung mit Hilfe der Nebenläufigkeitskontrolle überwacht und gegebenenfalls eingeschränkt. Je nach Ziel des jeweiligen Transaktionskonzepts sind die Einschränkungen dabei unterschiedlich stark. Das Isolationskonzept der klassischen Transaktionen hat zum Beispiel als Ziel, nebenläufige Transaktionen unabhängig und isoliert voneinander ablaufen zu lassen. Daher wird dort jegliche Art der gegenseitigen Einflußnahme unterbunden. Die geforderte Serialisierbarkeit verhindert alle Arten von Nebenläufigkeitsanomalien, aber auch jegliche Kommunikation zwischen den Transaktionen. Erweiterte Transaktionskonzepte haben oft zum Ziel, die strenge Serialisierbarkeit und damit auch die Isolation aufzugeben und in unterschiedlichem Maße Kommunikation zwischen Transaktionen zuzulassen. Da unerwünschte Nebenläufigkeitsanomalien schwer zu handhaben sind, wird in der Regel versucht, Serialisierbarkeit generell beizubehalten, und diese nur zwischen definierten Kommunikationspartnern oder zu bestimmten Zeitpunkten aufzuheben. Die erweiterten Transaktionskonzepte unterscheiden sich stark im Umfang der erlaubten Kommunikation und in der Flexibilität, mit der Kommunikationspartner festgelegt werden.