In der Informatik und insbesondere in Datenbanken wird eine Transaktion wie eine Reservierung, ein Kauf oder eine Zahlung über eine Reihe von Operationen implementiert, die die Datenbank von einem Zustand A - vor der Transaktion - in einen späteren Zustand B und Mechanismen ändern Es ist möglich zu erhalten, dass diese Sequenz gleichzeitig atomar , kohärent , isoliert und dauerhaft ( ACID ) ist.
Die meisten hierarchischen und relationalen Datenbankverwaltungssysteme auf dem Markt ermöglichen die Durchführung atomarer, kohärenter, isolierter und nachhaltiger Transaktionen. NoSQL- Systeme behaupten dies.
Das Konzept der Transaktion basiert auf dem Konzept des Synchronisationspunkts ( Synchronisationspunkt ), der einen stabilen Zustand des betrachteten Computersystems darstellt, insbesondere seiner Daten.
Atomarität Eine Transaktion muss in allem oder in nichts erfolgen, dh vollständig oder gar nicht; Konsistenz Die Datenkonsistenz muss in allen Fällen sichergestellt werden, auch in Fehlerfällen, in denen das System zum vorherigen konsistenten Zustand zurückkehren muss. Konsistenz wird durch funktionale Regeln hergestellt. Beispiel: Eine Immobilientransaktion kann lange dauern. IT wird als funktionales Verfahren betrachtet, das aus mehreren IT-Transaktionen besteht (Reservierung, Kaufvorschlag, Kompromiss, notarielle Urkunde). Die Zwischenstufen werden daher funktional über den Zustand des Apartmentobjekts verwaltet. Selbst wenn das Verfahren ausgeführt wird, bleibt das System zwischen jedem Schritt konsistent. Im Falle eines Abbruchs des Verfahrens (eine Art Rollback der Immobilientransaktion) stellen die Funktionsregeln die Wohnung wieder zum Verkauf. Es gibt viele Verfahrensfälle, die nicht von einer einzelnen IT-Transaktion behandelt werden können. Der Designer muss die Funktionsregeln angeben, die die Statusänderungen der betreffenden Objekte steuern, und das Äquivalent des Festschreibens und Zurücksetzens der Prozedur manuell verwalten. Isolierung Die Transaktion wird in einem isolierten Modus ausgeführt, in dem nur die zu ändernden Daten angezeigt werden, während auf einen neuen Synchronisierungspunkt gewartet wird. Das System garantiert anderen Transaktionen, die parallel auf demselben System ausgeführt werden, die Sichtbarkeit vergangener Daten. Dies wird dank der vom DBMS festgelegten Systemsperren erreicht. Das folgende Beispiel zeigt eine funktionalere Isolation, die eine Anwendungssperre implementiert: Ein Akteur gibt eine Bestellung im Hinblick auf einen Kontext auf. Dieser Kontext darf sich bei der Validierung seiner Bestellung nicht geändert haben, da die Bestellung sonst möglicherweise ihre gesamte Bedeutung verliert. Um zu verhindern, dass sich der Kontext ändert, können Sie ihn vor dem Lesen sperren. Aber es ist oft ein Konsument von Computerressourcen und für andere unpraktisch, insbesondere wenn die Reflexion und Eingabe mehrere Minuten dauert. Im Management reicht es im Allgemeinen aus, zum Zeitpunkt der Aktualisierung einfach zu überprüfen, ob sich der Kontext nicht geändert hat: Optimistisch wird die Isolation a posteriori überprüft; Haltbarkeit Wenn die Transaktion abgeschlossen ist, befindet sich das System entweder nach einer erfolgreichen Transaktionsänderung oder nach einem Fehler, der zu einer Rückkehr zum vorherigen stabilen Zustand führt, in einem dauerhaften stabilen Zustand. Nachhaltigkeit ist häufig mit der Stapelverarbeitung ( Stapelverarbeitung ) oder der asynchronen Replikation verbunden, die Emissionen erzeugt. Die nachgelagerte Anwendung hat nicht das Recht, die vorherige Transaktion, die das Ereignis ausgelöst hat, in Frage zu stellen. Andernfalls würde dies bedeuten, dass diese Transaktion das System nicht in einem konsistenten Zustand belassen hat. Die vorgelagerte Anwendung muss daher vor der Verbreitung der Informationen alles sorgfältig prüfen. Wenn die funktionale Architektur nicht rein ist, ist es häufig erforderlich, Ablehnungen zu verwalten. Diese außergewöhnlichen Behandlungen müssen dann spezifiziert werden, damit die Ausschussprodukte durch ein oft komplexes Funktionsverfahren recycelt werden. Daher die Bedeutung der Konsistenz der Transaktion in Bezug auf das gesamte System.Beispielsweise besteht während eines Computervorgangs zum Überweisen von Geld von einem Bankkonto auf ein anderes Bankkonto die Aufgabe, Geld vom Quellkonto abzuheben, und eine Einzahlungsaufgabe vom Zielkonto. Das Computerprogramm, das diese Transaktion ausführt, stellt sicher, dass beide Vorgänge fehlerfrei ausgeführt werden können. In diesem Fall wird die Änderung dann auf beiden Konten wirksam. Ist dies nicht der Fall, wird der Vorgang abgebrochen. Beide Konten behalten ihre Anfangswerte. Dies garantiert die Konsistenz der Daten zwischen den beiden Konten.
Computertransaktionen sind in DBMS weit verbreitet.
Diese alte Technik, die häufig mit Transaktionsmonitoren wie IBM CICS , BULL TDS und Siemens UTM praktiziert wird , wird heute häufig in Webanwendungsarchitekturen und in Client-Server- Anwendungen verwendet .
In der Tat sieht nichts mehr wie eine Webseite aus als ein synchroner Bildschirm:
Das Problem bei dieser Betriebsart besteht darin, dass manchmal eine Folge von mehreren Bildschirmen oder Seiten erforderlich ist, um eine vollständige ACID- Transaktion zu entwickeln . Es war die Merise- Methode , die diese Konzepte zum ersten Mal definierte:
Diese Aufgabe wird einer Pseudotransaktion gleichgesetzt, die aus Sicht des Monitors eine technische Transaktion ist, aber natürlich erst nach Abschluss der Sequenz wirklich funktioniert.
Aber :
Fragen :
Die Antworten der Ältesten sind auch die, die heute in „neuen“ Technologien verwendet werden:
Wir verstehen, warum das System zusammenbrechen würde, wenn wir System-Sperren (SGBD) in der gesamten Kette setzen, deren Dauer nicht kontrollierbar ist. Dies ist der springende Punkt der Pseudotransaktion. Die Strategie der Isolationskontrolle ist jedoch grundsätzlich funktional.
Die Pseudotransaktion ist daher ACID, aber die Funktionsregeln sind so, dass die Konsistenz zwischen jeder Pseudotransaktion in einer Sequenz durch das Fehlen jeglicher Aktualisierung der Datenbank garantiert wird.
Eine gut gestaltete Client / Server-Anwendung verwendet ebenfalls Pseudotransaktionen, aber der Kontext wird in der Client-Anwendung behandelt, wodurch der Server entlastet wird. Das typische Diagramm lautet wie folgt:
Das ergibt N + 1 Pseudotransaktionen.