Transaktionsverarbeitung: Grundlagen
Eine Transaktion dient dazu, eine endliche Folge von Operationen zusammenhängend in einem Arbeitsschritt ("Unit of Work") auszuführen. Entweder es werden alle Operationen ausgeführt oder gar keine. Der Vorgang beginnt mit dem Befehl "begin" und endet mit "commit". Mit "rollback" wird die Transaktion abgebrochen und der Vorgang in den ursprünglichen Zustand überführt. Der Beginn und das Ende einer Transaktion werden auch als Transaktionsgrenzen bezeichnet. Eine Transaktion ist ferner eine Folge von Aktivitäten oder Operationen auf Daten beziehungsweise Objekte.
Ein konsistenter Zustand eines Systems wird über diese Folge von Operationen in einen neuen konsistenten Zustand überführt, wie dies in der nächsten Abbildung verdeutlicht wird. Der Zustand zwischen dem Beginn und dem Ende einer Transaktion ist nicht konsistent. Klassisch wurde eine Transaktion nur lokal auf einem Rechner ausgeführt. Alle Ressourcen (typischerweise Datenbanken) befanden sich also auf einem Mainframe oder auf einem Server-Rechner. Im Zuge der Verteilung von Anwendungen musste man sich nun Gedanken darüber machen, wie man Transaktionen, die verteilte Ressourcen nutzen, also verteilte Transaktionen in den Griff bekommt.
Zu den wesentlichen Problemen, die in lokalen und verteilten Transaktionen behandelt werden müssen, gehören die Nebenläufigkeitskontrolle (Concurrency Control), das Recovery bei Fehlersituationen und die Koordination der beteiligten Softwareinstanzen beim Abschluss der Transaktion. Alle an einer Transaktion beteiligten Instanzen müssen sich über den Transaktionszustand sowie den Transaktionsausgang einig sein. Man sagt, sie verfügen über denselben Transaktionskontext oder befinden sich im selben Thread-of-Control.
Mehrere Transaktionsmodelle wurden erforscht: Das klassische Transaktionsmodell wird als Flat Transaction bezeichnet. Hier gelten die strengen ACID-Korrektheitskriterien. Im Lauf der Jahrzehnte wurden weitere Transaktionsmodelle wie offen und geschlossen geschachtelte (nested) sowie langlebige (long-lived) Transaktionen implementiert. Geschachtelte Transaktionen ermöglichen den Aufruf weiterer Subtransaktionen innerhalb einer Transaktion. Bei geschlossen geschachtelten Transaktionen werden die ACID-Eigenschaften über die Gesamtransaktion hinweg eingehalten, bei offen geschachtelten Transaktionen werden die Subtransaktionen zwischendurch beendet, wodurch Inkonsistenzen in Kauf genommen werden. Kompensationsstrategien sind daher im Fehlerfall notwendig. Verteilte Transaktionen untersuchte man vor allem zur Transaktionsunterstützung in Client-Server-Architekturen. Dabei wurde die Anwendung der ACID-Korrektheitskriterien immer wieder neu diskutiert. Durchgesetzt hat sich letztendlich in der Praxis im Wesentlichen das Konzept der flachen Transaktionen, auch in verteilter Umgebung.
Bei verteilten Transaktionen hat sich das Koordinator-Teilnehmer-Modell durchgesetzt. Ein Koordinator entscheidet über den Ausgang der Transaktion und steuert die Koordination mit den Teilnehmern über ein Commit- oder Completion-Protokoll. Hierfür hat sich das Zwei-Phasen-Commit-Protokoll (2PC) etabliert, allerdings gibt es viele 2PC-Implementierungen, die nicht miteinander kompatibel sind. Wichtig ist auch, dass das 2PC-Protokoll ein blockierendes Protokoll ist und damit in der Praxis einige Probleme auftreten können, wenn der Koordinator ausfällt. Transaktionen bleiben dann offen, und Sperren werden nicht aufgelöst.
Im Folgenden werden Standards der Transaktionsverarbeitung erläutert