Was sind Transaktionen und wie kann ich sie nutzen?

Automatisch übersetzt von Deepl

Stellen Sie sich vor, Sie überweisen 200.000 € von einem Bankkonto auf ein anderes. Sie heben den Betrag vom Ursprungskonto ab und zahlen ihn dann auf das Zielkonto ein. So weit ist alles normal, und in einer perfekten Welt wird der Vorgang gelingen. Leider kann in der realen Welt einiges schief gehen. Irgendetwas passiert und das Geld ist verloren. Das ist sehr schade.

Nun, Transaktionen sind dazu da, um sicherzustellen, dass dies bei Ihren Anwendungen nicht passiert! In diesem Blog-Beitrag werden die Verwendung und die Bedeutung von Transaktionen sowie verschiedene Szenarien, die zeigen, wie sie Ihr Unternehmen retten können, im Detail erläutert.

Was sind Transaktionen?

In der Dokumentation heißt es dazu:

Transaktionen sind eine Reihe von zusammenhängenden Datenänderungen, die innerhalb eines Prozesses an einer Datenbank vorgenommen werden. Eine Transaktion wird erst dann dauerhaft in einer Datenbank gespeichert, wenn sie validiert ist. Wenn eine Transaktion nicht abgeschlossen wird, entweder weil sie abgebrochen wird oder aufgrund eines externen Ereignisses, werden die Änderungen nicht gespeichert.

Es ist wichtig zu beachten:

Wenn Sie verschachtelte Transaktionen verwenden, hängt das Ergebnis jeder Untertransaktion von der Validierung oder dem Abbruch der übergeordneten Transaktion ab. Wenn die übergeordnete Transaktion validiert wird, werden die Ergebnisse der Untertransaktionen bestätigt (Validierung oder Stornierung). Wird hingegen die übergeordnete Transaktion storniert, werden alle Untertransaktionen unabhängig von ihren jeweiligen Ergebnissen storniert.

Ausführlichere Informationen über Transaktionen finden Sie in der Dokumentation.

Verwendung von Transaktionen

Es ist schwierig, sich Geschäftsanwendungen vorzustellen, die keine Transaktionen verwenden, und doch habe ich sie von Zeit zu Zeit gesehen! Wenn ich mit den Anwendungsentwicklern über das Fehlen von Transaktionen spreche, höre ich Sätze wie „oh, das hat bisher immer funktioniert“ oder sogar „wir haben immer Glück gehabt“. Meiner Meinung nach sollte Glück kein Designkonzept für Geschäftsanwendungen sein.

Ein klassisches Beispiel für die Verwendung von Transaktionen ist die Buchhaltung. In den Jahresabschlüssen werden zwei Kategorien erfasst: Aktiva und Passiva. Beide müssen berechnet und gespeichert werden (vollständig, niemals teilweise), oder sie müssen ganz unangetastet bleiben.

Ein weiteres Beispiel ist ein Versandsystem, bei dem die Erstellung eines Auftrags den Bestand im Lager verringert. Anstatt sich auf Glück zu verlassen, müssen wir sicherstellen, dass sowohl der Auftrag als auch die Bestandsaufzeichnungen gemeinsam erstellt oder geändert werden. Was auch immer geschieht, entweder werden beide Vorgänge abgeschlossen oder storniert.

Sie können sich eine Transaktion als eine Art große Klammer vorstellen:

  • Sie öffnen sie (START TRANSACTION Befehl),
  • Operationen in der Datenbank durchführen (Datensätze erstellen/ändern/löschen – aus einer oder mehreren Tabellen),
  • dann schließen Sie sie, indem Sie entweder validieren (VALIDATE TRANSACTION Befehl) oder Abbrechen (CANCEL TRANSACTION command) ALLE Operationen abbrechen.

Neben Datenbankoperationen auf niedriger Ebene sind Transaktionen auch in einer Benutzeroberfläche gut einsetzbar. Stellen Sie sich ein Rechnungseingabeformular vor, das ein Listenfeld (oder Unterformular) mit Produktartikeln (die in einer anderen Tabelle gespeichert sind) verwendet … oder Kunden und Kontakte … oder Kontakte und Telefonnummern. Die Liste geht weiter und weiter ….

Ihr Benutzer möchte eine Rechnung ändern. Vielleicht ändert er eine oder mehrere Positionen und entscheidet sich dann, auf die Schaltfläche Abbrechen zu klicken und davon auszugehen, dass alle Änderungen an den Rechnungspositionen rückgängig gemacht (nicht gespeichert) werden. Sie könnten dies mit komplexen Arrays oder einfach mit Hilfe einer Transaktion handhaben.

Hoffentlich verwenden Sie bereits Transaktionen.

Verwendung verschachtelter Transaktionen

Szenario eins: eine Kontaktanwendung

Nehmen wir an, Sie haben eine einfache Struktur mit 2 Tabellen: Kunden und Kontakte. Sie haben ein Kundeneingabeformular mit einem Listenfeld für Kontaktdatensätze. Ein Doppelklick auf einen Datensatz öffnet ein Kontakteingabeformular mit weiteren Details zu diesem Kontakt.

Das könnte folgendermaßen ablaufen:

  • Ein Endbenutzer öffnet einen Kundendatensatz und ändert den Straßennamen.
  • Dann öffnet er den Kontakt „A“, ändert das Geburtsdatum und schließt das Kontaktformular mit einem Klick auf die Schaltfläche OK.
  • Anschließend öffnet er den Kontakt „B“, ändert etwas und beschließt dann, seine Änderungen zu verwerfen.
  • Zurück im Kundenformular klickt der Endbenutzer auf eine OK-Schaltfläche, um seine Aktivitäten abzuschließen.

Der Benutzer erwartet, dass seine Änderung an Kontakt „A“ gespeichert wird, während die Änderung an Kontakt „B“ nicht gespeichert wird. Die Änderungen am Kundendatensatz selbst sollten natürlich auch gespeichert werden.

Mit verschachtelten Transaktionen lässt sich dies leicht bewerkstelligen. Verwenden Sie einfach eine Transaktion im Kundenformular und eine weitere Transaktion im Kontaktformular. Kein Problem!

Szenario zwei: automatische Stapelverarbeitung

Ein völlig anderes Szenario – aber mit demselben Konzept – ist die automatische Stapelverarbeitung (Berechnungen, Import usw.):

  • Mitten in einem komplexen Stapelverarbeitungsauftrag müssen Sie den Prozess aus irgendeinem Grund anhalten(z. B. wenn Sie auf fehlerhafte Daten stoßen oder wenn ein Benutzer einen Abbruch/Beendigung wünscht).

Bei einer einstufigen Transaktion können Sie nur alle Vorgänge abbrechen – oder mittendrin aufhören, was zu einer unklaren Situation führt. Sie denken jetzt vielleicht: „Ich würde nicht mittendrin aufhören, sondern den Vorgang beenden, bevor ich aufhöre“. Das ist toll, aber wie würden Sie mit Stromausfällen, Abstürzen, Hardwarefehlern und anderen unerwarteten Fehlern umgehen?

Da dies nicht möglich ist … und man sich nicht auf Glück verlassen kann … sollte das System so konzipiert sein, dass zuverlässige Daten gewährleistet sind.

Denken Sie daran …

Transaktionen geben Ihnen die Kontrolle über diese Art von Situationen. Verwenden Sie einzelne Transaktionen für jeden Vorgang (Datenimport, Berechnungen usw.), die in eine übergeordnete Transaktion eingebettet sind (um alle Vorgänge abzubrechen oder zu validieren).

Wenn eine Transaktion aus irgendeinem Grund (Absturz, Stromausfall usw.) nicht abgeschlossen werden kann, haben Sie keine Angst! Alle bereits durchgeführten Operationen werden rückgängig gemacht, da noch nichts von der Top-Level-Transaktion validiert worden ist.

Thomas Maul
• VP of Strategy, 4D Product Line • Als die deutsche Niederlassung von 4D 1988 gegründet wurde, trat Thomas dem Unternehmen als Technischer Direktor bei und half beim Aufbau der 4D Entwicklergemeinschaft in Deutschland und Österreich. Nach vielen Jahren, in denen er Kunden bei technischen Problemen unterstützte und zunehmend in Vertriebs- und Managementfragen involviert war, wurde er 1999 zum Geschäftsführer von 4D Deutschland befördert. Seit 2005 war er als Mitglied der Geschäftsleitung an der weltweiten Strategie des Unternehmens beteiligt, was zu seiner jetzigen Position als Vice President of Strategy, 4D Product Line, führte, wo er für die Definition und Umsetzung der Gesamtstrategie für die 4D Produktlinie in Verknüpfung mit den Teams für Programm, F&E, Vertrieb und Marketing verantwortlich ist.