DE4216871C2 - Ausführungsordnen zum Sicherstellen der Serialisierbarkeit verteilter Transaktionen - Google Patents

Description

Die vorliegende Erfindung betrifft ganz allgemein eine verteilte Datenverarbeitung, und insbesondere ein Transaktionsverarbeitungssystem, in dem Teiloperationen in zugehörigen Transaktionen so verteilt werden, daß zumindest eine Operation in einer zweiten Transaktion durchgeführt wird, bevor eine erste Transaktion mit einer in Konflikt stehenden Operation ausgeführt wird. Die vorliegende Erfindung betrifft insbesondere ein Verfahren und eine Vorrichtung zur (Ablauf-) Planung bzw. Steuerung der Durchführung von in Konflikt stehenden Operationen gemäß verfügbaren Systemelementen (resource) und zum Sicherstellen, daß die Ergebnisse der in Konflikt stehenden Operationen in der gleichen Reihenfolge wie die Reihenfolge der Durchführung der in Konflikt stehenden Operationen ausgeführt werden.

Eine erwünschte Eigenschaft eines Datenverarbeitungssystems besteht in der Fähigkeit des Systems, daß es sich von einem teilweisen Systemausfall, der Speicherschreiboperationen unterbricht, wieder erholt. Wenn ein Anwendungsprogramm gerade eine Speicherschreiboperation zum Zeitpunkt eines Systemausfalls oder -fehlers ausführt, ist es sehr wahrscheinlich, daß der Speichereintrag fehlerhaft wird. Um das Wiederherstellen von Speichereinträgen nach einem teilweisen Systemausfall zu ermöglichen, d. h. die Fehler bei den Speichereinträgen zu beheben, ist es für ein Anwendungsprogramm notwendig, Sicherungskopien (backup copies) der Einträge in einem nicht flüchtigen Speicher abzuspeichern und zu halten. Wenn das Datenverarbeitungssystem wieder gestartet wird, werden die Speichereinträge, die wiedergeholt werden sollen, durch die Sicherungskopien ersetzt.

Um das Erstellen von Sicherungskopien und das Wiederherstellen (recovery) von Speichereinträgen zu ermöglichen und zu erleichtern, stellt das Betriebssystem typischerweise einen eingerichteten Satz von Speichermanagementprozeduren zur Verfügung, die von einem Anwendungsprogramm aufgerufen werden können, um eine "Wiederherstellungseinheit" zu definieren. Die Wiederherstellungseinheit (recovery unit) besteht aus Programmanweisungen (program statements) zwischen einer "Start"-Anweisung und einer "Ausführ"-Anweisung (commit statement). Alle Anweisungen in der "Wiederherstellungseinheit" müssen abgeschlossen sein, bevor die Speichereinträge, die durch die Anweisungen in der Wiederherstellungseinheit modifiziert werden, für eine nachfolgende Verarbeitung verfügbar gemacht werden. Die "Start"-Anweisung entspricht der Erstellung einer Sicherungskopie in einem nichtflüchtigen Speicher und die "Ausführ"-Anweisung entspricht dem Ersetzen der Sicherungskopie durch eine modifizierte Version. Die Anweisungen in der "Wiederherstellungseinheit" spezifizieren Operationen in einer einzelnen "Transaktion". Beim Beheben eines teilweisen Systemfehlers wird die Überprüfung des nichtflüchtigen Speichers (nonvolatile memory) zeigen, daß die Operationen in der einzelnen "Transaktion" entweder alle abgeschlossen sind oder keine von ihnen abgeschlossen ist.

In einem verteilten Datenverarbeitungssystem können die Operationen in einer einzelnen Transaktion Dateien in unterschiedlichen Datenbanken modifizieren und auf die Dateien können andere Prozesse zugreifen. Während des Betriebs der Transaktion können die Dateien zeitweise inkonsistent sein, obwohl die Dateien nach der Beendigung der Transaktion konsistent sein werden. Ein typisches Beispiel ist der Transfer von Geldern von einem Konto auf ein anderes, bei dem ein erstes Konto belastet wird, und kurz darauf ein anderes Konto kreditiert wird. Während der Zwischenzeit sind die beiden Konten inkonsistent, da die Summe der beiden Konten nicht die Gesamtgelder der beiden Konten wiedergibt. Wegen der Inkonsistenz, wenn Dateien durch eine Transaktion modifiziert werden, ist es bekannt, anderen Prozessen zu verbieten, auf die Dateien zuzugreifen, bis die Modifikation abgeschlossen ist. Die Wiederherstellbarkeit kann in diesem Beispiel durch Ausführen einer Überweisung für beide Dateien zum gleichen Zeitpunkt und am gleichen Ort sichergestellt werden. Durch z. B. das Ändern eines einzelnen Zeichens (flag) können die Sicherungskopien jeder Datei durch die modifizierten Versionen der Dateien zum gleichen Zeitpunkt ersetzt werden. Bei vielen Anwendungen ist es jedoch wünschenswert, die Operationen einer Transaktion auf eine Vielzahl von Prozessoren oder Prozessen in einem Datenverarbeitungssystem zu verteilen und die Transaktion durch Ausführen der Operationen in jedem Prozeß oder Prozessor auszuführen, wobei eine gewisse Variabilität zwischen den Ausführungszeitpunkten zugelassen wird. Bei diesen Anwendungen wird ein "Gesamtausführungsprotokoll" (atomic commitment protocol) typischerweise dazu verwendet, die Wiederherstellbarkeit sicherzustellen. Das Protokoll erfordert den Austausch von Informationen über den Zustand der Transaktion zwischen den Prozessoren oder Prozessen. Um die Transaktion zu identifizieren, die ausgeführt wird, wird der Transaktion typischerweise eine individuelle bzw. einzigartige "Transaktionsidentifikationsnummer" (transaction identification number) zugewiesen.

Ein weit verbreitet verwendetes Gesamtausführungsprotokoll ist als "Zweiphasenausführungsprotokoll" (two-phase commit protocol) bekannt. In einem etwas elementaren Beispiel für dieses Protokoll wird einem Prozessor oder einem Prozeß des Datenverarbeitungssystems die Rolle eines Koordinators, der eine Transaktion initialisiert bzw. auslöst, zugewiesen. Um eine Transaktion zu beginnen, sendet der Koordinator einen Vorbereitungsbefehl (prepare command) an alte Prozessoren oder Prozesse, die an der Transaktion teilnehmen.

Mit dem Empfang des "Vorbereitungsbefehls" führt jeder Prozessor oder Prozeß, der an der Transaktion teilnimmt, eine "Start"-Operation durch, indem er zuerst "Schreibsperren" (write locks) für den Speicher, auf den durch die Transaktion zugegriffen wird, plaziert, die Transaktionsidentifikationsnummer in den Dauerspeicher (permanent memory) schreibt, um daran zu erinnern, daß er für die Transaktion bereitsteht bzw. vorbereitet ist, und dann eine Bestätigung zurück zu dem Koordinationsprozessor sendet, aber noch nicht seinen Teil der Transaktion durchführt. Der Koordinator wartet auf die Bestätigungen aller Teilnehmer. Wenn der Koordinator Bestätigungen von allen Teilnehmern erhält bzw. empfängt, schreibt der Koordinator in den Permanentspeicher eine Liste der Teilnehmer und eine Notiz, daß die Transaktion nunmehr abgeschlossen ist, wonach der Koordinator "Ausführ"-Befehle an alle Teilnehmer sendet bzw. ausgibt. Der Koordinator kann jedoch eine Nachricht von einem Teilnehmer empfangen, die anzeigt, daß er sich nicht auf die Transaktion vorbereiten kann, oder es kann fehlschlagen, daß der Koordinator Bestätigungen von allen Teilnehmern nach einer vorgegebenen Zeitdauer empfängt, möglicherweise nachdem der Koordinator den "Vorbereitungs"-Befehl erneut abgesendet hat. In diesem Fall gibt der Koordinator einen "Abbruch"-Befehl (abort command) an alle Teilnehmer aus.

Mit dem Empfang des "Ausführung"-Befehls überprüft jeder Teilnehmer seinen Dauerspeicher nach der Transaktionsidentifikationsnummer, um zu bestimmen, ob er sich auf die Transaktion vorbereitet hat, und, wenn er sich vorbereitet hat, führt er seinen Teil der Transaktion durch, und führt dann eine "Ausführung"-Operation ("COMMIT" operation) durch, um den Zustand bzw. Status des Dauerspeichers zu aktualisieren und die Transaktionsidentifikationsnummer (transaction ID) aus dem Dauerspeicher in einen "Gesamt"-Schritt ("atomic" step) zu löschen (clear) und hebt (erase) schließlich die Schreibsperren (write locks) auf. Dann sendet der Teilnehmer eine Bestätigung zurück an den Koordinator. Wenn der Koordinator die Bestätigungen von allen Teilnehmern erhalten hat, löscht er die Liste der Teilnehmer aus dem Dauerspeicher und die Transaktion ist abgeschlossen.

In vielen verteilten Datenverarbeitungssystemen ist es den Prozessoren oder Prozessen gestattet, mehrere Transaktionen gleichzeitig bzw. simultan durchzuführen. Im gewöhnlichen Fall führt jeder Prozessor oder Prozeß Transaktionen durch, die für den Prozessor oder den Prozeß lokal bzw. örtlich (local) sind, und führt auch Abschnitte von globalen Transaktionen durch. Z. B. können in einem verteilten Datenbanksystem Abfragen und Aufbereitungen (edits) in der lokalen Datenbank lokal auftreten und einige der Modifikationen können global durchgeführt werden. Eine direkte Anwendung des Zweiphasenausführungsprotokolls, das obenstehend beschrieben wurde, kann in einem solchen System zufriedenstellenderweise durchgeführt werden, solange den globalen Transaktionen eine hohe Priorität gegenüber den lokalen Transaktionen eingeräumt werden kann. Aber den Einsatz von Schreib- und Lesesperren kann unnötigerweise lokale Transaktionen einschränken, die gleichzeitig verarbeitet werden könnten.

Eine zusätzliche Schwierigkeit ergibt sich, wenn es erwünscht ist, globale Transaktionen gleichzeitig in mehreren Prozessoren oder Prozessen eines verteilten Datenverarbeitungssystems bzw. Verarbeitungssystems auszuführen. Es ist unpraktisch, es einem Prozessor oder einem Prozeß zu gestatten, ein globales Bild aller Konflikte in allen Prozessoren oder Prozessen zu sehen bzw. zu haben. Ohne ein globales Bild ist es jedoch schwierig für einen Prozessor oder einen Prozeß sicherzustellen, daß es eine Korrelation bzw. einen Zusammenhang zwischen seiner Serieneinordnung (seriability order) und den Serieneinordnungen der anderen Prozessoren oder Prozesse gibt. Das Zeitmarkieren (time stamping) von Transaktionsnachfragen (transaction requests) und von Datenaktualisierungen (data updates) ist ein Verfahren, das verwendet worden ist, um diesem Problem der Gleichzeitigkeitssteuerung und -kontrolle zu begegnen. Im allgemeinen ist eine Gleichzeitigkeitssteuerung in einem verteilten Datenverarbeitungssystem auf Kosten einer beschränkten Autonomie der lokalen Prozessoren und Prozesse oder durch Sperren (locking) erreicht worden.

Dem Problem des globalen Systemstillstands bzw. der globalen Blockierung (global deadlock) muß auch begegnet werden, wann immer globale Transaktionen gleichzeitig durchgeführt werden sollen. Eine bekannte Lösung dafür besteht darin, einen globalen Transaktionsmanager vorzusehen, der entscheidet, ob gleichzeitige globale Transaktionsnachfragen (global transaction request) gesendet werden oder nicht. Ein Beispiel dafür wird in Y. Breitbart usw., "Reliable Transaction Management in a Multidatabase System", Proc. of the ACM SIGMOD conf. on Management of Data, Atlantic City, New Jersey, June 1990, Seiten 215-224 beschrieben. Der globale Planer (global scheduler) verfolgt globale Transaktionsnachfragen nach lokalen Sperrungen von Datenbeständen, indem er einen globalen Sperrmechanismus verwendet. Jedes globale Datenfeld (data item) hat eine globale Sperre, die ihm zugeordnet ist. Eine globale Transaktion, die nur ein Datenfeld zu lesen braucht, fragt nach einer globalen Lesesperre. Sperren stehen in Konflikt zueinander, wenn sie von zwei unterschiedlichen Transaktionen bezüglich des gleichen Datenfelds nachgefragt werden und zumindest eine der nachgefragten Sperren eine Schreibsperre ist. Wenn zwei globale Transaktionen in Konflikt stehende (conflicting) globale Sperren nachfragen, sorgt der Planer dafür, daß eine der Transaktionen nicht durchgeführt bzw. verarbeitet wird, da er weiß, daß die beiden Tansaktionen einen Konflikt auf der lokalen Seite verursachen würden. Der Planer verwendet ein strenges Zwei-Phasen-Sperren (two-phase locking) zum Zuweisen globaler Sperren zu globalen Transaktionen und unterhält einen globalen "Wartegraphen" (wait for graph). Der globale Wartegraph ist ein gerichteter Graph G = (V, E), dessen Satz aus Punkten (vertices) V ein Satz aus globalen Transaktionen ist, wobei eine Kante (edge) T_i → T_j zu E gehört, wenn und nur wenn die globale Transaktion T_i auf eine globale Sperre wartet, die einer globalen Transaktion T_j zugewiesen wird. Wenn eine globale Transaktion auf eine globale Sperre wartet, dann wird der Transaktionszustand "blockiert" und die Transaktion ist im "globalen Wartegraphen" enthalten. Die Transaktion wird nur dann wieder aktiv, nachdem sie globale Sperren erhalten kann, auf die sie gewartet hat. Um einen globalen Stillstand oder eine globale Blockierung zu verhindern, wird der "globale Wartegraph" immer azyklisch erstellt. Um eine Datenkonsistenz beim Vorkommen von Ausfällen und Fehlern sicherzustellen, verwendet der Planer ebenfalls einen "Ausführungsgraphen" (commit graph) und einen "Warte- auf-Ausführungsgraphen" (wait-for-commit-graph), um zu bestimmen, wann eine Ausführungsoperation geplant werden kann. Der Ausführungsgraph CG = <TS, E< ist ein ungerichteter, zweigeteilter Graph (bipartite graph), dessen Satz aus Knoten (nodes) TS aus einem Satz globaler Transaktionen (Transaktionsknoten) und einem Satz lokaler Plätze (Platzknoten) besteht. Die Kanten von E kön­ nen nur Transaktionsknoten mit Platzknoten verbinden. Eine Kante (T_i, S_j) ist in E, wenn und nur wenn die Transaktion T_i an einem Platz (site) S_j ausgeführt wurde und die Ausfüh­ rungsoperation für T_i für die Verarbeitung eingeplant wor­ den ist. Nachdem die Ausführoperation für T_i abgeschlossen worden ist, wird T_i von dem Ausführungsgraphen zusammen mit allen Kanten die auf T_i treffen, entfernt. Eine globale Datenbankkonsistenz wird erreicht bzw. sichergestellt, wenn der Ausführungsgraph keine Schleifen enthält. Der Warte-auf- Ausführungsgraph ist ein gerichteter Graph G = (V, E), des­ sen Satz an Punkten V aus einem Satz globaler Transaktionen besteht. Eine Kante T_i → T_j ist in E, wenn und nur wenn T_i seine Ausführung (execution) abgeschlossen hat, aber seine Ausführungsoperation (commit operation) noch anhängig ist, und T_j ist eine Transaktion, deren Ausführungsopera­ tion abgeschlossen oder abgebrochen werden sollte, bevor die Ausführung von T_i geplant werden kann. Der Planer ver­ wendet den nachfolgenden Algorithmus zum Aufbauen des War­ te-auf-Ausführungsgraphen und zum Planen einer Ausführungs­ operation der Transaktion T_i:

• 1. Für jeden Platz S_k an dem T_i ausgeführt wird, addiere kurzfristig die Kante T_i → S_k zum Ausführungsgraphen hinzu.
• 2. Wenn der vergrößerte Ausführungsgraph keinen Zyklus enthält, dann wird die globale Ausführungsoperation zur Verarbeitung vorgelegt und die kurzzeitigen Kanten werden zu dauerhaften Kanten.
• 3. Wenn der vergrößerte Ausführungsgraph einen Zyklus enthält, dann:
  • a) werden die Kanten T_i → T_i1, . . ., T_i → T_im in den Warte-auf- Ausführungsgraphen eingefügt. Der Satz {T_i1, T_i2, . . ., T_im} besteht aus all den Transaktionen, die in dem Zyklus auftreten, welcher als Ergebnis des Hinzuaddierens der neuen Kanten zu dem Ausführungsgraphen erzeugt worden ist.
  • b) Entferne die temporären Kanten aus dem Ausführungsgraphen.

Die Transaktion T_i muß jedoch nicht notwendigerweise auf die Beendigung jeder Transaktion T_ik warten, so daß T_i → T_ik wird. Sie kann für die Einplanung in einer Ausführungsoperation bereit sein, nachdem einige Transaktionen T_ik erfolgreich ausgeführt worden sind, so daß T_i → T_i1 (0 < 1 < r) ist (und in einigen Fällen reicht eine erfolgreiche Ausführung von nur einer dieser Transaktionen aus, um die Ausführung der Transaktion zu planen!).

Aufgabe der vorliegenden Erfindung ist es, die Serienverarbeitung unter verteilten Transaktionen in einem Verarbeitungssystem sicherzustellen.

Mit dem Problem der Serienverarbeitung bzw. der Serialisierung des Zugriffs auf Objekte durch ein Datenverarbeitungssystem befaßt sich US-4,249,241. Zugriffsbeschränkungen werden automatisch durchgesetzt, indem auf mögliche Zugriffskonflikte hin überprüft wird und im Falle des Vorliegens eines Zugriffskonflikts der Zugriff gesperrt wird. Die Abwicklung möglicher Zugriffskonflikte erfolgt also basierend auf dem Sperren bzw. der Freigabe des Zugriffs auf ein bestimmtes Objekt. Zudem können vom Benutzer selbst Sperrungen vorgegeben werden.

Mit dem Problem der Koordinierung der Ausführung von Transaktionen befaßt sich Korth, Silberschatz "Database System Concepts", S. 491-503, McGraw-Hill, 1991. Widerherstellungsschemata sowie Schemata für den zeitgleichen Ablauf von Transaktionen werden vorgestellt. Insbesondere erfolgt eine genaue Beschreibung des Zwei-Phasen-Ausführungsprotokolls.

Mit dem Problem der Serialisierbarkeit von Multidatenbank-Transaktionen befaßt sich Georgakopoulos et al. "On Serializability of Multidatabase Transactions Through Forced Local Conflicts", Proceedings of Seventh International Conference on Data Engineering, Kobe, Japan, April 1991. Darin wird ein Transaktions- Managementmechanismus vorgestellt, der die Ausführung von Multidatenbank- Transaktionen lediglich dann erlaubt, wenn ihre relative serielle Reihenfolge in allen lokalen Datenbanken gleich ist. Hierzu werden direkte Konfikte zwischen Multidatenbank-Transaktionen generiert, die es gestatten, die relative serielle Reihenfolge der Untertransaktionen festzustellen.

Diese Aufgabe wird durch das Verfahren nach Anspruch 1 bzw. durch das digitale Computersystem zum Verarbeiten von Transaktionen nach Anspruch 15 gelöst. Die Unteransprüche definieren besondere Ausführungsformen der Erfindung.

Die vorliegende Erfindung garantiert gemäß einem Ausführungsbeispiel eine serielle Verarbeitung bzw. Serialisierbarkeit (serializability) unter verteilten Transaktionen in einem Datenverarbeitungssystem, indem die Transaktionen selektiv ausgeführt und abgebrochen werden, um eine Reihenfolge der Ausführung (order of commitment) zu ermöglichen bzw. zu unterstützen, die die gleiche ist, wie eine Reihenfolge der Durchführung von in Konflikt stehenden Teiloperationen der Transaktionen. Wenn die Transaktion ausgeführt wird, werden Ergebnisse der Teiloperationen einem Zustandsspeicher eingegeben. Wenn die Operation abgebrochen wird, werden die Ergebnissse der Teiloperationen gelöscht. Z. B. steht eine erste Speicherzugriffsoperation in einer ersten Transaktion mit einer zweiten Speicherzugriffsoperation in einer zweiten Transaktion in Konflikt, wenn die zwei Speicherzugriffsoperationen die gleiche Speicherstelle betreffen und zumindest eine der Operationen eine Schreiboperation ist.

Bei einem typischen bekannten Transaktionsverarbeitungssystem kann eine zweite Transaktion nur Daten lesen, die von einer ersten Transaktion geschrieben worden sind, nachdem die erste Transaktion ausgeführt worden ist. Diese Einschränkung ist eine ausreichende Bedingung dafür, eine Wiederherstellung des Systems sicherzustellen. Um die vorliegende Erfindung in diesem Fall praktisch umzusetzen, wenn eine zweite Transaktion eine Leseoperation durchführt, bevor eine in Konflikt stehende Schreiboperation einer ersten Transaktion ausgeführt wird, zu einem Zeitpunkt, wenn die zweite Transaktion noch nicht ausgeführt worden ist, wird die erste Transaktion abgebrochen, um sicherzustellen, daß die Reihenfolge, in der die Transaktionen ausgeführt werden, nicht unterschiedlich zu der Reihenfolge ist, in der die in Konflikt stehenden Operationen durchgeführt werden bzw. durchgeführt werden müssen.

Die vorliegende Erfindung erlaubt jedoch die Auslegung eines Transaktionsverarbeitungssystems, in dem eine zweite Transaktion Daten lesen kann, die von einer Schreiboperation einer ersten Transaktion geschrieben worden sind, bevor die erste Transaktion ausgeführt wird. In diesem Fall, und zwar in Abhängigkeit von der jeweiligen Reihenfolge, in der die zwei in Konflikt stehenden Operationen auftreten, kann eine der beiden Transaktionen abgebrochen werden, um sicherzustellen, daß die Reihenfolge der Ausführung der Transaktionen die gleiche ist wie die Reihenfolge der Durchführung der in Konflikt stehenden Operationen. Des weiteren, und zwar um eine Wiederherstellbarkeit zu gewährleisten, sollten beide Transaktionen in dem Fall abgebrochen werden, bei dem eine Leseoperation einer Schreiboperation nachfolgt und die Leseoperation durchgeführt wird, bevor die Schreiboperation abgebrochen wird. Im allgemeinen wird in einem Transaktionsverarbeitungssystem, in dem eine zweite Transaktion Daten lesen kann, die von einer Schreiboperation einer ersten Transaktion geschrieben worden sind, die Wiederherstellbarkeit durch einen Prozeß kaskadierender Abbrüche (cascading aborts) unterstützt. Das Abbrechen einer Transaktion erfordert das zusätzliche Abbrechen aller anderen Transaktionen, die Daten gelesen haben, welche von abgebrochenen Transaktionen geschrieben worden sind.

In Fällen, wo Speicheradressen oder Speicherzugriffsoperationen vor dem Erzeugen oder Vorbereiten der Transaktionen bekannt sind, kann die erforderliche Ausführungsreihenfolge vor der Vorbereitung der Transaktionen bestimmt werden. Ansonsten werden Konflikte festgestellt, wenn die Speicheradressen während des Vorbereitens der Transaktionen bestimmt werden.

Die Ausführungsreihenfolge (commitment order) wird durch Ausführen (committing) einer ausgewählten Transaktion erzwungen, für die ein Ergebnis vorbereitet worden ist, und indem andere Transaktionen abgebrochen werden, für die ein Ergebnis gerade in Vorbereitung ist oder vorbereitet wird und für die die Ausführung im Gegensatz zu der vorher definierten Ausführungsreihenfolge und der Ausführung der ausgewählten Transaktionen steht. Z. B. wird die Transaktion, die ausgeführt werden soll, ausgewählt, indem Prioritäten, die den Transaktionen zugeordnet sind, verglichen werden, indem ein Einreihen bzw. Einordnen der Transaktionen in eine Liste durchgeführt wird, indem eine Ausführungsnachfrage von einem Koordinator gemacht wird oder indem eine Strategie verwendet wird, um die Anzahl anderer Transaktionen zu minimieren, die als Ergebnis der Auswahl abgebrochen werden. In einem Vielprozessorsystem, in dem ein globaler Koordinator mit einer Vielzahl von Transaktionsprozessoren mittels "Vorbereitungs" (prepare) und "Ausführungs"-Befehlen kommuniziert, wird die Minimierungsstrategie bevorzugterweise dazu verwendet, um die Bestätigung zu verzögern, daß eine Transaktion "vorbereitet" worden ist, bis der "Abbruchsatz" (abort set) der Transaktion minimiert worden ist.

Vorteilhafte Weiterbildungen der vorliegenden Erfindung sind den Unteransprüchen zu entnehmen.

Weitere Vorteile und Anwendungsmöglichkeiten der vorliegenden Erfindung werden aus der nachfolgenden Beschreibung bevorzugter Ausführungsformen in Verbindung mit den beiliegenden Zeichnungen deutlich. Es zeigen:

Fig. 1 ein Blockdiagramm eines digitalen Computers, der für eine Transaktionsverarbeitung ausgelegt ist;

Fig. 2A ein Flußdiagramm einer Prozedur zum Durchführen einer Transaktionsverarbeitung in dem Computer der Fig. 1, indem zwischen zwei Zustandsspeicherbanken geschaltet wird;

Fig. 2B eine alternative Prozedur zum Betreiben des Digitalcomputers der Fig. 1 für Transaktionsverarbeitung, indem die Kopien von nur denjenigen Dateneinträgen des Zustandsspeichers bewahrt bzw. geschützt werden, die durch eine Transaktion modifiziert wurden;

Fig. 3A Verschiedene Planungsmöglichkeiten für in Konflikt stehende Speicherzugriffsoperationen von verteilten Transak­ tionen für den Fall, wo eine zweite Transaktion die Schreib­ daten einer ersten Transaktion nur lesen kann, nachdem die erste Transaktion ausgeführt worden ist;

Fig. 3B verschieden Planungsmöglichkeiten für in Konflikt stehende Speicherzugriffsoperationen verteilter Transaktio­ nen für den Fall, wo eine zweite Transaktion die Schreibda­ ten einer ersten Transaktion lesen kann, bevor die erste Transaktion ausgeführt wird;

Fig. 4A einen digitalen Computer, der in Übereinstimmung mit einer bevorzugten Ausführungsform der vorliegenden Er­ findung konfiguriert ist, um eine Ausführungsreihenfolge zu bewirken, in der verteilte Transaktionen in der Reihen­ folge, in der in Konflikt stehende Komponentenoperationen durchgeführt werden, ausgeführt werden;

Fig. 4B ein verteiltes Datenverarbeitungssystem, das eine Vielzahl von digitalen Computern gemäß Fig. 4A enthält;

Fig. 5 eine Planungsprozedur, die von einer Transaktions­ planungskomponente des digitalen Computers nach Fig. 4A verwendet wird.

Fig. 6 eine Organisation einer Transaktionsliste und zuge­ höriger Zeiger (pointer), die von dem Transaktionsplaner (transaction scheduler) zum Planen der Durchführung von Komponentenoperationen verteilter Transaktionen verwendet werden;

Fig. 7 ein schematisches Diagramm, das einer Datenstruktur entsprechend eines Graphen der Ausführungsreihenfolge zwi­ schen verteilten Transaktionen mit in Konflikt stehenden Komponentenoperationen entspricht;

Fig. 8 ein Pictogramm des Graphen, der den Daten, die in der Datenstruktur nach Fig. 7 gespeichert sind, entspricht;

Fig. 9 ein Flußdiagramm einer Prozedur, die sich auf die Datenstruktur nach Fig. 7 bezieht, um die Ausführungsreihen­ folge zu bewirken;

Fig. 10 ein Flußdiagramm einer Prozedur zum Auswählen einer Transaktion, die ausgeführt werden soll;

Fig. 11 eine Prozedur zum Detektieren einer in Konflikt stehenden Speicherzugriffsoperation während der Vorberei­ tung einer Transaktion;

Fig. 12 einen modifizierten Graphen, in dem Schreib/Lese- Konflikte von anderen Konflikten unterschieden sind;

Fig. 13 ein Flußdiagramm einer rekursiven Prozedur zum Si­ cherstellen einer Wiederherstellung beim Durchführen kaska­ dierender Abbrüche;

Fig. 14 ein Zustandsdiagramm eines digitalen Computers nach Fig. 4A, wenn der digitale Computer in einem Vielprozessor­ system der Fig. 4B zum Verarbeiten von lokaler und globalen Transaktionen verwendet wird;

Fig. 15 ein Flußdiagramm von Ausführungsplanungsprozeduren, die globale Transaktionen auf unterschiedliche Art und Wei­ se wie lokale Transaktionen behandeln;

Fig. 16 ein Flußdiagramm einer Prozedur zum Ausführen und Unterbrechen von Transaktionen in Antwort auf Signale von einem Koordinator einer globalen Transaktion;

Fig. 17 ein Blockdiagramm, das einen Ausführungsreihenfolge- Koordinator zeigt, der die vorliegende Erfindung verwendet, welche in einem herkömmlichen Transaktionsverarbeitungssystem zwischen einem Transak­ tionsmanager und einem Systemelementmanager verwendet wird; und

Fig. 18 ein Zustandsdiagramm eines Transaktionsverarbeitungssystems der Fig. 17.

Im nachfolgenden ist unter einer ausgeführten Transaktion auch immer eine Transaktion zu verstehen, die bestätigt wird, da jeder Teilnehmer nach dem Ausführen einer "Ausführung"-Operation ("COMMIT" operation) eine Bestätigung an den Koordinator sendet (vgl. Seite 5, erster Absatz).

In Fig. 1 wird ein Blockdiagramm gezeigt, das einen digitalen Computer 20 zeigt, der für eine Transaktionsverarbeitung ausgelegt ist. Der Computer 20 enthält eine zentrale Verarbeitungseinheit 21 zum Ausführen programmierter Befehle; einen flüchtigen Speicher mit wahlfreiem Zugriff 22 (random access memory) zum Halten und Speichern von Instruktionen oder Daten; einen nichtflüchtigen Speicher 23 wie z. B. ein Festplattenlaufwerk, eine Eingangs/Ausgangs-Einheit 24 und eine Echtzeituhr 25. Der nichtflüchtige Speicher 23 enthält einen Programmspeicher 26, in dem Programme gespeichert sind, und einen Arbeitsspeicherbereich 27 (scratch memory area) zum Speichern von Dateneinträgen (data records).

Typischerweise führt der Digitalcomputer 20 Programme aus, die von einem Programmspeicher 26 zu dem flüchtigen Speicher mit wahlfreiem Zugriff 22 transferiert worden sind. Während der Ausführung eines Programms ist es oft notwendig, eine Menge von Daten zu bearbeiten, die die Kapazität des flüchtigen Ramspeichers 22 übersteigt. In diesem Fall werden Dateneinträge abwechselnd gespeichert und aus dem Arbeitsspeicherbereich 27 wiedergeholt.

Ein allgemeines Problem, das bei Digitalcomputern 20 auf­ tritt, ist die Wahrscheinlichkeit, daß die Ausführung von Befehlen durch die zentrale Verarbeitungseinheit (central processing unit) wegen eines Hardwareausfalls oder -feh­ lers, eines Softwarefehlers oder eines Ausfalls der Span­ nungsversorgung gestört bzw. unterbrochen wird. Z. B. würde ein Ausfall der Spannungsversorgung das Verschwinden von Daten und Programmen verursachen, die in dem flüchtigen Ramspeicher gespeichert sind. Das Problem des Verlustes von Daten in dem flüchtigen Ramspeicher 22 aufgrund eines Ausfalls der Spannungsversorgung kann gelöst werden, indem die Sicherungskopien der Daten in den nicht flüchtigen Spei­ cher 23 gespeichert werden. Die Sicherungskopien (back-up copies) müssen jedoch auf eine Art und Weise gemacht wer­ den, die die Möglichkeit eines Ausfalls während einer Schreiboperation bezüglich des nichtflüchtigen Speichers 23 berücksichtigt. In diesem Fall könnte der Dateneintrag, der durch die Schreiboperation bewerkstelligt worden ist, ver­ fälscht worden sein und muß deshalb gelöscht werden.

Zur Lösung des Problems eines möglichen Ausfalls oder Feh­ lers bei dem Beschreiben eines nichtflüchtigen Speichers ist ein Programmierverfahren entwickelt werden, das als "Transaktionsverarbeitung" (transaction processing) bezeich­ net wird und das sicherstellt, daß ein Abschnitt des nicht­ flüchtigen Speichers (der nachfolgend als "Zustandsspei­ cher" (state memory) bezeichnet wird) entweder durch eine Transaktion nicht beeinflußt wird oder geeigneterweise durch die Ergebnisse einer Transaktion aktualisiert wird, wenn Ausfälle oder Fehler vorliegen. Eine Transaktionsverar­ beitung basiert auf der Technik des Erstellens einer Siche­ rungskopie des Zustandsspeichers bevor die Ergebnisse der Transaktion in den Zustandsspeicher geschrieben werden, aber auch auf der Technik des Schreibens eines Hinweises in den nichtflüchtigen Speicher für entweder eine erste Verar­ beitungsphase, in der die Sicherungskopie erstellt wird, oder für eine zweite Verarbeitungsphase, in der die Ergebnisse der Transaktion in den Zustandsspeicher geschrieben werden, um anzuzeigen, welche Kopie während eines Ausfalls oder Fehlers möglicherweise verfälscht worden ist. Zum Erstellen einer Sicherungskopie des Zustandsspeichers enthält der nichtflüchtige Speicher 23 z. B. zwei Zustandsspeicherbanken 28 und 29. Um einen Hinweis dafür zu erzeugen, welche Zustandsspeicherbank möglicherweise durch einen Ausfall verfälscht worden ist, enthält der nichtflüchtige Speicher 23 eine Speicherstelle 30 zum Speichern eines Kennzeichens oder Zeichens (switch or flag).

Bei der Rückkehr von einem Ausfall ist es wünschenswert, die Transaktion zu wissen, die zuletzt von der zentralen Verarbeitungseinheit 21 durchgeführt worden ist, so daß die Verarbeitung am Punkt der Unterbrechung wieder aufgenommen werden kann, ohne daß eine Transaktion wiederholt oder übersprungen wird. Für diesen Zweck wird immer dann, wenn der Zustandsspeicher in einer der Speicherbanken 28 oder 29 aktualisiert wird, ein Transaktionsidentifikationscode 31, 32 in den Zustandsspeicher zusammen mit den Zeitpunkten 33, 34 eingeschrieben, zu denen die Ergebnisse der Transaktion zuerst in den Zustandsspeicher eingeschrieben (d. h. eingegeben bzw. ausgeführt (committed)) wurden.

In Fig. 2A wird ein Flußdiagramm einer Prozedur zum Gewährleisten dargestellt, daß, wenn nach einem Ausfall weitergearbeitet wird, der Zustandsspeicher des Computers 20 nach Fig. 1 entweder von einer Transaktion unbeeinflußt worden ist oder durch das Ergebnis der Transaktion in geeigneter Weise aktualisiert wird. Man nehme z. B. an, daß das Computersystem nach einem Ausfall der Spannungsversorgung wieder eingeschaltet wird. In einem ersten Schritt 51 liest die zentrale Verarbeitungseinheit (CPU) 21 den Wert des Kennzei­ chens 30, das in dem nichtflüchtigen Speicher 23 gespei­ chert ist. Dieses Kennzeichen (switch) zeigt an, welche der zwei Zustandsspeicherbanken 28, 29 möglicherweise durch den Ausfall der Spannungsversorgung verfälscht worden ist. Beim Schritt 52 bezieht sich die zentrale Verarbeitungseinheit 21 auf den Wert des Kennzeichens, um die Zustandsspeicher­ bank zu lesen, von der bekannt ist, daß sie nicht ver­ fälscht worden ist, und um eine "Arbeitskopie" (working copy) der Daten in der anderen Zustandsspeicherbank zu ma­ chen. Deshalb haben nach dem Schritt 52 beide Zustandsspei­ cherbanken 28 und 29 den gleichen Inhalt. Des weiteren kann der Transaktionsidentifizierer 31, 32 und die Ausführungs­ zeit (commit time) 33, 34 überprüft werden, um die Stelle in einem Programm der nächsten Transaktion, die bearbeitet werden soll, zu finden.

Beim Schritt 53 wird diese Verarbeitung fortgesetzt, indem die Daten in der Arbeitskopie des Zustandsspeichers modifi­ ziert werden, indem die Ergebnisse der Transaktion, die verarbeitet wird, geschrieben werden. Das Ende der Verarbei­ tung der Transaktion wird beim Schritt 54 erreicht. Um die Ergebnisse der Transaktion in den Zustandsspeicher zu über­ tragen bzw. einzugeben, wird der Wert des Kennzeichens im Schritt 55 geändert und beim Schritt 56 wird der geänderte Wert des Kennzeichens in die Kennzeichenstelle 30 des nichtflüchtigen Speichers geschrieben. Wenn das Kennzeichen von der zentralen Verarbeitungseinheit 21 während der Rück­ kehr von einem Ausfall gesehen wird, dann hat das Schreiben des geänderten Werts des Kennzeichens in den nichtflüchti­ gen Speicher den Effekt des Sicherstellens, daß das übertra­ gene bzw. eingegebene Ergebnis der Transaktion entweder keinen Effekt bezüglich des Zustandsspeichers hat oder in geeigneter Weise den Zustandsspeicher aktualisiert, und zwar abhängig davon, ob der Ausfall vor oder nach dem Ein­ schreiben des Kennzeichenwertes in den nichtflüchtigen Spei­ cher aufgetreten ist oder nicht. Da der Wert des Kennzei­ chens 30 ein einzelnes Bit ist und das Kennzeichen 30 in einem Eintrag gespeichert ist, der unterschiedlich zu den Einträgen der Zustandsspeicherbanken ist, bleibt jeder Aus­ fall, der während des Schreibens dieses einzelnen Bits auf­ tritt, ohne Folge. In diesem Fall wird keine der Zustands­ speicherbanken verfälscht bzw. beeinträchtigt, so daß der Wert des Kennzeichens keine Rolle spielt.

Das Verfahren zum Übertragen des Ergebnisses einer Trans­ aktion gemäß Fig. 2A ist ziemlich ineffizient, wenn das Ergebnis einer Transaktion nur einen kleinen Abschnitt des Zustandsspeichers modifiziert. In diesem Fall wird beim Schritt 52 ziemlich viel Zeit für nicht notwendiges Kopie­ ren von Dateneinträgen, die nicht modifiziert worden sind, verbraucht. Dieses nicht notwendige Kopieren kann durch die etwas komplexere Prozedur gemäß Fig. 2B unterbunden werden.

Beim ersten Schritt 61 der Fig. 2B wird das Kennzeichen aus dem nichtflüchtigen Speicher gelesen. Als nächstes über­ prüft die zentrale Verarbeitungseinheit beim Schritt 62, ob das Kennzeichen gesetzt ist. Wenn das der Fall ist, dann ist ein Ausfall bzw. Fehler während der Verarbeitungsphase aufgetreten, in der die Ergebnisse einer Transaktion in den Zustandsspeicher eingegeben worden sind, wie weiter unten beschrieben wird. Beim Schritt 63 werden deshalb Ein­ träge, die in der Zustandsspeicherbank 29 aufbewahrt sind, in die Zustandsspeicherbank 28 kopiert. Beim Schritt 64 wird dann das Kennzeichen im nichtflüchtigen Speicher ge­ löscht.

Um dann eine Transaktion beim Schritt 65 zu verarbeiten, werden Dateneinträge von der Zustandsspeicherbank 28 gelesen und in den Zwischenspeicherbereich 27 übertragen. Dann werden die Einträge des Zwischen­ speichers gemäß den Ergebnissen der Transaktion modifiziert. Wenn die Transaktion abgeschlossen ist, was beim Schritt 67 festgestellt wird, werden beim Schritt 68 die originalen Daten der Einträge, die modifiziert werden sollen, von der Zustandsspeicherbank 28 in die Zustandsspeicherbank 29 kopiert. Dann wird beim Schritt 69 das Kennzeichen im nichtflüchtigen Speicher gesetzt. Beim Schritt 70 werden dann die Ergebnisse der Transaktion übertragen (committed), indem die modifizierten Daten in die Zustandsspeicherbank 28 eingeschrieben werden. Schließlich wird beim Schritt 64 das Kennzeichen im nichtflüchtigen Speicher gelöscht (cleared). Die Verarbeitung der nächsten Transaktion beginnt im Schritt 65.

Wie oben mit Bezug auf die Fig. 2A oder Fig. 2B beschrieben wurde, wird angenommen, daß die Transaktionen in einer Sequenz durch die zentrale Verarbeitungseinheit 21 des Computers 20 nach Fig. 1 abgearbeitet bzw. verarbeitet werden. Die vorliegende Erfindung erlaubt es jedoch, daß die Verarbeitung der Transaktionen so verteilt wird, daß die Ergebnisse für eine zweite Transaktion vorbereitet bzw. erzeugt werden können, bevor die Ergebnisse der ersten Transaktion übertragen werden. Wie nachfolgend mit Bezug auf Fig. 5 beschrieben wird, gestattet die vorliegende Erfindung die Verwendung eines Transaktionsplaners, der ein Echtzeitbetriebssystem oder einen Planer umfaßt, um die zentrale Verarbeitungseinheit während der Zeit effektiver auszunutzen bzw. zu beschäftigen, während der sie ansonsten auf die Beendigung von Eingabe/Ausgabe- oder Speicherzugriffsoperationen warten würde. Indem es erlaubt wird, daß eine zweite Transaktion Teiloperationen durchführt, bevor eine erste Transaktion ihre Ergebnisse übertragen bzw. eingegeben (committed) hat, wird jedoch das Problem der Inkonsistenz eingeführt, bis das Planen der Operationen und die Ausführung bzw. Übertragung der Transaktionen mit einer bestimmten Durchführungsreihenfolge übereinstimmt. Insbesondere sollten die Transaktionen in der gleichen Reihenfolge ausgeführt werden, wie die Reihenfolge, in der die zugehörigen in Konflikt stehenden (d. h. nicht kommutierenden (non-commuting) Operationen durchgeführt werden.

Wenn das Planen der Komponentenoperationen und die Ausführung der Transaktionen diese Eigenschaft der "Ausführungsreihenfolge" (commitment ordering) haben, kann auch gezeigt werden, daß in einem verteilten Verarbeitungssystem (wie es weiter unten in Verbindung mit der Fig. 4B beschrieben wird) eine globale Serienverarbeitung gewährleistet wird, wenn nur "Gesamtübertragung" (atomic comitment) eingesetzt wird, um die verschiedenen Prozessoren des Systems zu koordinieren. Dies wird durch eine ziemlich aufwendige mathematische Überprüfung belegt, welche an die vorliegende Beschreibung angehängt ist (vergleiche Anhang I). Von einem praktischen Gesichtspunkt bzw. Standpunkt aus bedeutet dieses Ergebnis, daß die Vorteile der vorliegenden Erfindung auf ein herkömmliches verteiltes Transaktionsverarbeitungssystem angewendet werden können, indem jeder Transaktionsprozessor oder Knoten des Systems ohne Modifikation des globalen Planers oder des Protokolls für das Verteilen globaler Transaktionen durch das System modifiziert wird.

Ein herkömmliches Transaktionsverarbeitungssystem stellt sicher, daß eine zweite Transaktion die Schreibdaten einer ersten Transaktion nur lesen kann, nachdem die erste Transaktion ausgeführt worden ist. Dies ist eine ausreichende aber nicht notwendige Bedingung dafür, eine Wiederherherstellung sicherzustellen. Bei einer ersten Ausführungs­ form der vorliegenden Erfindung kann diese Bedingung bzw. dieser Zustand auch beibehalten werden, um die erforder­ liche Größe des nichtflüchtigen Speichers zu minimieren und das zu vermeiden, was als "kaskadierende Abbrüche" be­ kannt ist, um eine Wiederherstellbarkeit zu erreichen. Bei dieser ersten Ausführungsform werden Transaktionen im we­ sentlichen verarbeitet, wie es in Fig. 2B gezeigt wird, wobei die Leseoperationen Einträge aus der Zustandsspeicher­ bank lesen und diese Einträge zum Zwischenspeicher trans­ ferieren, wie es beim Schritt 65 der Fig. 2B gezeigt wird. Die Schreiboperationen werden vorbereitet, indem die Einträ­ ge des Speichers, wie beim Schritt 66 der Fig. 2B gezeigt wird, modifiziert werden, aber die Ergebnisse jeder Trans­ aktion werden in separaten Einträgen des Zwischenspeichers 27 gehalten, auch dann, wenn die Schreiboperationen ver­ schiedener Transaktionen die gleichen Einträge in dem Zu­ standsspeicher betreffen. Der Grund dafür, besteht darin, daß der Effekt, den solche in Konflikt stehenden Schreibope­ rationen auf den Zustandsspeicher haben, durch die Reihen­ folge, in der die Transaktionen ausgeführt werden, festge­ legt ist.

Fig. 3A zeigt drei unterschiedliche Möglichkeiten für die Planung einer ersten Transaktion mit einer Schreiboperation und einer zweiten Transaktion mit einer in Konflikt stehen­ den Leseoperation. Im allgemeinen stehen zwei Operationen miteinander in Konflikt, wenn sie Speicherzugriffsoperatio­ nen sind, die auf die gleiche Stelle in dem Zustandsspei­ cher zugreifen wollen, und wenn zumindest eine der Operatio­ nen eine Schreiboperation ist. Aus einer Überprüfung folgt, daß von den drei Planungsmöglichkeiten die Möglichkeit (b) das Erfordernis der Übertragungsreihenfolge verletzt und deshalb eine Inkonsistenz bezüglich des Zustands des Zu­ standsspeichers verursachen kann. Wegen der Tatsache, daß die Schreiboperation W_x nicht austauschbar mit der Leseope­ ration R_x ist, kann das Ergebnis für die Transaktion T₂ für die Planungsmöglichkeit (b) unterschiedlich zu dem Er­ gebnis für die Transaktion T₂ für die Planungsmöglichkeit (a) sein. Um konsistente Ergebnisse zu erhalten, erlaubt es die vorliegende Erfindung, daß in Konflikt stehende Ope­ rationen von zwei Transaktionen in einer ausgewählten Rei­ henfolge eingeplant werden können, um die Systemelemente, die für die zentrale Verarbeitungseinheit erhältlich sind, möglichst effizient zu nutzen. Sie stellt aber auch die Konsistenz bzw. Verträglichkeit oder Widerspruchsfreiheit sicher, indem sie eine Ausführungsreihenfolge festlegt, die die gleiche ist, wie die Reihenfolge, in der die in Konflikt stehenden Operationen durchgeführt werden. Inkon­ sistente Planungsmöglichkeiten, wie z. B. die Möglichkeit (b) in Fig. 3A, werden unterbunden, indem eine in Konflikt stehende Transaktion abgebrochen wird, wenn eine ausgewähl­ te Transaktion ausgeführt wird, oder indem die Ausführung einer ausgewählten Transaktion solange verzögert wird, bis die in Konflikt stehende Transaktion ausgeführt worden ist.

In dem Beispiel nach Fig. 3A kann man z. B. annehmen, daß die erste geplante Operation eine Leseoperation R_x der zwei­ ten Transaktion T₂ ist, wie es in den Möglichkeiten (b) und (c) gezeigt wird. Wenn die Transaktion T₂ vor der Trans­ aktion T₁ ausgeführt wird, wie es in der Möglichkeit (c) gezeigt ist, ergibt sich keine Inkonsistenz, da das Planen in Übereinstimmung mit der Ausführungsreihenfolge ist. Wenn jedoch die erste Transaktion T₁ vor der zweiten Transaktion T₂ ausgeführt wird, wie es in der Möglichkeit (b) gezeigt wird, muß die zweite Transaktion T₂ abgebrochen werden, da ansonsten die Ausführung der zweiten Transaktion T₂ die Ausführungsreihenfolge verletzen würde und zu inkonsisten­ ten Ergebnissen führen könnte.

Die vorliegende Erfindung ermöglicht weiterhin die Planung von Operationen so, daß eine zweite Transaktion T₂, die Schreibdaten einer ersten Transaktion T₁ lesen kann, bevor die erste Transaktion T₁ ausgeführt wird. In diesem Fall kann die Wiederherstellbarkeit durch einen Prozeß von kaska­ dierenden Abbrüchen garantiert werden, wie es weiter unten mit Bezug auf die Fig. 12 und 13 beschrieben wird. Für den Fall einer ersten Transaktion T₁ mit einer Schreibopera­ tion W_x und einer zweiten Transaktion T₂ mit einer in Kon­ flikt stehenden Leseoperation R_x gibt es sechs Planungsmög­ lichkeiten, die in der Fig. 3B als (a) bis (f) angegeben sind. Zwei dieser Planungsmöglichkeiten können die Ausfüh­ rungsreihenfolge (commitment ordering) verletzen und können deshalb zu inkonsistenten Ergebnissen führen. Die vorliegen­ de Erfindung verhindert das Auftreten dieser Planungsmög­ lichkeiten, indem sie die Reihenfolge bestimmt in welcher die in Konflikt stehenden Operationen durchgeführt werden, und dann die Ausführung einer ausgewählten Transaktion ver­ zögert oder eine in Konflikt stehende Operation, wenn not­ wendig, abbricht, um eine Ausführungsreihenfolge zu erzwin­ gen. Um der Leseoperation in der zweiten Transaktion zu erlauben, die Schreibdaten einer Schreiboperation einer ersten Transaktion zu lesen, behält der Digitalcomputer 20 der Fig. 1 z. B. eine Arbeitskopie des Zustandsspeichers in dem Zwischenspeicherbereich 27. Immer dann, wenn eine Schreiboperation durchgeführt wird, werden die Ergebnisse der Schreiboperation in die Arbeitskopie des Zustandsspei­ chers in den Zwischenspeicherbereich eingeschrieben und separate Kopien der geschriebenen Einträge werden in den Zwischenspeicher in Verbindung mit jeder Transaktion gehal­ ten. Wenn die Transaktion ausgeführt wird, werden nur dann die Ergebnisse der Schreiboperation der Transaktion in den Zustandsspeicher eingeschrieben. Bei der Ausführungsform des Falls 2 bezieht sich die Leseoperation auf die Arbeits­ kopie des Zustandsspeichers in dem Zwischenspeicher, und nicht auf den Zustandsspeicher selbst, wie im Fall 1, so daß im Fall 2 die Leseoperationen die eingeschriebenen Da­ ten früherer Schreiboperationen lesen.

In Fig. 4A wird ein Blockdiagramm der Programmierung und der Datenstrukturen gezeigt, die in dem digitalen Computer 20 der Fig. 1 für Planungstransaktionen und für das Erzwingen der Ausführungsreihenfolge verwendet werden. Um die Ergebnisse der Transaktionen in den Zustandsspeicher 28, 29 zu übertragen und von Ausfällen bzw. Fehlern zurückzukehren, ist der digitale Computer mit einem Systemelement-Manager (RM) 81 versehen, der z. B. die Operationen, die in Fig. 2B gezeigt werden, durchführt. Im allgemeinen ist ein Systemelementmanager (RM) eine Softwarekomponente, die die Zustandsspeicher-Systemelemente, welche durch übertragende Transaktionen berührt werden, so betreibt, daß der Speicherzustand der Systemelemente wiederhergestellt bzw. erneut gespeichert werden kann, bevor die Transaktion übertragen bzw. ausgeführt wird, indem alle Änderungen, die durch die Transaktion eingeführt werden, effektiverweise unterdrückt bzw. rückgängig bzw. gelöscht werden. Anders ausgedrückt, der Systemelementmanager stellt sicher, daß die Transaktionen die Eigenschaft der "Gesamtheit" (atomicity) oder von "alles oder nichts"-Semantik bezüglich ihrer Zustandsspeicher-Systemelemente haben. Ein Systemelement ist typischerweise aber nicht notwendigerweise ein Datenelement oder ein Datenobjekt. Beispiele für Systemelementmanager (resource manager) sind typischerweise in Datenbanksystemen (DSB's = data base systems) in Listenmanagern und Cache-Managern zu finden.

Um die Komponentenoperationen der Transaktionen in der effizientesten Reihenfolge auf der Basis von verfügbaren Systemelementen für den Computer zu planen, ist ein Transaktionsplaner (TS = transaction scheduler) 82 vorgesehen. Bevorzugterweise enthält der Transaktionsplaner 82 eine Art von Echtzeitbetriebssystem, das eine Transaktionsliste (TL) 83 verwaltet und managed, wie es weiter unten mit Bezug auf Fig. 5 beschrieben wird.

Bevorzugterweise wird das Vorhandensein von in Konflikt stehenden Operationen in Echtzeit festgestellt, wenn die Transaktionen durchgeführt werden, wie weiter unten mit Bezug auf Fig. 11 beschrieben wird. In Übereinstimmung mit der Ausführungsreihenfolge bestimmt die Reihenfolge, in der in Konflikt stehende Operationen durchgeführt werden, eine erforderliche Reihenfolge der Ausführung der Transak­ tionen, und diese erforderliche Reihenfolge der Ausführung wird in einem Seriengraphen (USG = undecided transactions serializability graph) für nicht entschiedene Transaktionen 84 aufgezeichnet, der eine Datenstruktur im Speicher ist und der weiter unten mit Bezug auf die Fig. 7 und 8 be­ schrieben wird. Die "nichtentschiedenen Transaktionen" sind die Transaktionen, die noch ausgeführt werden oder abge­ brochen werden. Um die Ausführungsreihenfolge festzulegen, werden Transaktionen für die Ausführung ausgewählt und Transaktionen werden selektiv abgebrochen durch einen Aus­ führungsreihenfolgen-Koordinator (COCO = committment order coordinator) 85, der weiter unten mit Bezug auf die Fig. 10 und 15 beschrieben wird.

Die vorliegende Erfindung kann in Verarbeitungssystemen mit Einzelprozessor eingesetzt werden, in denen eine Vielzahl von Transaktionen gleichzeitig durchgeführt werden, indem Komponentenoperationen geplant werden, oder kann in einem Multiprozessorsystem eingesetzt werden, in dem Komponenten­ operationen der gleichen Transaktion gleichzeitig in unter­ schiedlichen Prozessoren durchgeführt werden. Ein Vielpro­ zessorsystem 90 wird in Fig. 4B erläutert. In diesem Fall sind drei digitale Computer 91, 92, 93 über einen Kommunika­ tionskanal 94 miteinander verbunden und die Kommunikation wird durch die Transaktionsplaner (TS) 95, 96, 97 gesteu­ ert. In dem Multiprozessorsystem 90 kann jeder der Transak­ tionsplaner 95, 96, 97 die Rolle eines Koordinators anneh­ men und globale Transaktionen an die anderen Transaktions­ planer ausgeben. Diese globalen Transaktionen werden z. B. gemäß dem bekannten Zwei-Phasenausführungsprotokoll koordi­ niert, wie oben mit Bezug auf den Stand der Technik erläu­ tert worden ist und unten mit Bezug auf die Fig. 14, 15 und 16 weiter erläutert wird.

Die Transaktionsplaner können auch Zustandsinformationen über den Kommunikationskanal 94 austauschen. Insbesondere fallen die Transaktionsverarbeitungssysteme allgemein unter zwei breite Kategorien, die als Datenbankmanagementsysteme und objektorientierte Systeme bezeichnet werden, was davon abhängt, ob die Zustandsspeicherinformationen resident in den nichtflüchtigen Speicherdateien eines bestimmten der digitalen Computer 91, 92, 93 abgespeichert ist oder nicht oder ob die Zustandsinformationen mit vordefinierten Objek­ ten verbunden bzw. diesen zugeordnet sind, die von einem Computer zum anderen weitergegeben werden. Die vorliegende Erfindung ist jedoch in beiden Systemtypen anwendbar, da die vorliegende Erfindung insbesondere das Planen von Kompo­ nentenoperationen der Transaktionen und die Festlegung und das Erzwingen einer Ausführungsreihenfolge betrifft, und nicht besonders damit befaßt ist, wo der Zustandsspeicher im verteilten Verarbeitungssystem physikalisch angesiedelt oder aufrechterhalten wird.

Fig. 5 zeigt ein Flußdiagramm einer Prozedur, der ein Trans­ aktionsplaner für Echtzeitplanen von Komponentenoperationen oder Transaktionen in Übereinstimmung mit erhältlichen Sy­ stemelementen des digitalen Computers nachfolgt. Insbeson­ dere enthalten die Transaktionen Eingabe/Ausgabe und Spei­ cherzugriffe auf einen rotierenden Speicher wie z. B. Plat­ tenlaufwerke und möglicherweise mathematische Berechnungen, die von einen Coprocessor durchgeführt werden. Ohne Echt­ zeitplanen würde die zentrale Verarbeitungseinheit des digi­ talen Computers eine relativ lange Wartezeit benötigen, bis diese Operationen abgeschlossen sind, bevor sie die Komponentenoperationen anderer Transaktionen durchführen könnte.

Um die Systemelemente des digitalen Computers effektiver verwenden zu können, kann eine Transaktion Eingabe/Ausgabe und Speicherzugriffsnachfragen an die Eingabe/Ausgabe- und Speichereinheiten des Computers absenden bzw. ausgeben und dann ein Sperrzeichen (inhibit flag) setzen, das dem Planer anzeigt, daß die Verarbeitung der gegenwärtigen Transaktion gehemmt bzw. gesperrt werden soll, bis die Eingabe/Ausgabe- oder Speicherzugriffsoperation abgeschlossen ist. Schließ­ lich führt die Transaktion einen Software-Interrupt für den Transaktionsplaner aus, um dem Transaktionsplaner zu ermög­ lichen, die Ausführung (execution) zu einer anderen Transak­ tion zu transferieren. Wenn die nachgefragte Eingabe/Ausga­ be- oder Speicherzugriffsoperation abgeschlossen ist, gibt die Eingabe/Ausgabe- oder Speichereinrichtung einen Ab­ schluß-Interrupt aus, der von einer Interrupt-Behandlungs­ routine verarbeitet wird, die das Sperrzeichen der Transak­ tion zurücknimmt bzw. löscht, welche die Eingabe/Ausgabe- oder Speicherzugriffsoperation nachgefragt hat. Die Beendi­ gungsinterrupts der Eingabe/ Ausgabe- und Speicherzugriffe und Bearbeitungsprogramme (device handlers) für solche In­ terrupts sind bekannt.

Nachfolgend wird insbesondere auf den ersten Schritt 101 in Fig. 5 Bezug genommen, wobei der Transaktionsplaner auf einen Interrupt durch Entfernen des Textes der unterbroche­ nen Transaktion aus dem Prozessorstapelspeicher des digita­ len Computers und durch Unterbringen des Kontextes in einem entsprechenden Textspeicher für die unterbrochene Transak­ tion reagiert. Der Kontext enthält den Wert des Programmzäh­ lers, der auf die unterbrochene Speicherstelle in dem Trans­ aktionsprogramm hinweist, und enthält auch den Kontext bzw. Inhalt weiterer Register allgemeinen Zwecks des digitalen Computers.

Der Transaktionsplaner kann auch während einer anfänglichen Hochlaufphase (start-up) des digitalen Computers beim Schritt 102 betreten werden. Beim Schritt 102 werden die Transaktionsliste 83 und weitere Datenstruk­ turen, wie z. B. der nichtentschiedene Seriengraph (USG) zurückgenommen und Zeiger (pointers) werden initialisiert.

In den Transaktionsplaner kann auch am Ende der Vorbereitung für eine Transaktion eingetreten werden. In diesem Fall wird die Transaktion beim Schritt 103 markiert, um anzuzeigen, daß sie fertig ist, ausgeführt zu werden. Außerdem wird die gegenwärtige Zeit, die von der Echtzeituhr (25 in Fig. 1) angezeigt wird, in einer Speicherstelle abgespeichert, die der Transaktion zugeordnet ist, um die Zeit anzugeben, bei der die Transaktion fertig war. Es wird darauf hingewiesen, daß jedoch einige Programmteile (tasks), die auf der Transaktionsliste plaziert sind, sogenannte Hintergrundtasks mit niedriger Priorität sein können, die niemals abgeschlossen werden und Rechnerzeit, die nach dem Bedienen aller Transaktionen der Liste verbleibt, der zentralen Verarbeitungseinrichtung benötigen.

In den Transaktionsplaner kann auch am Ende der Interrupt-Routine für das Steuerprogramm (device handler) eingetreten werden. Der Schritt 111 löscht z. B. das Sperrzeichen (I in der Liste von Fig. 6) für die Transaktion, die die Eingabe/Ausgabe- oder Speicheroperation nachgefragt hat, wonach die Ausführung beim Schritt 101 damit fortfährt, die gegenwärtige bzw. gerade laufende Transaktion zu unterbrechen, um möglicherweise die Ausführung zu der Transaktion zurückzulenken, die nach der Eingabe/Ausgabe- oder Speicheropera­ tion nachgefragt hat.

Der Transaktionsplaner führt drei Hauptaufgaben (major tasks) durch: er antwortet auf Transaktionsnachfragen durch Plazieren der Transaktionen auf der Transaktionsliste; er löst die Ausführung bereitstehender Transaktionen aus und er plant die Durchführung von Komponentenoperationen der Transaktionen. Beim Schritt 104 überprüft der Transaktions­ planer z. B., ob eine Transaktion nachgefragt hat. Ein Trans­ aktionsplanner-Interrupt kann z. B. in Antwort auf ein Inter­ rupt-Signal von der Eingabe/Ausgabe-Einheit auftreten, der anzeigt, daß ein Benutzer oder ein anderer digitaler Compu­ ter nach der Durchführung einer Transaktion nachgefragt hat. In diesem Fall wird die Transaktionsnachfrage auf der Transaktionsliste beim Schritt 105 plaziert.

Fig. 6 zeigt ein spezielles Beispiel einer Transaktionsli­ ste 83. Die Transaktionsliste enthält eine Verbindungslist (linked list) von Transaktionsidentifikationsnummern 106. Mit jeder Transaktionsidentifikationsnummer sind ein Zeiger auf den nächsten Eintrag in der Verbindungsliste und Werte für eine Anzahl von Zeichen (V, R, I, G, P) verbunden. Die­ se Zeichen (flags) enthalten ein Gültigkeitszeichen V, das anzeigt, ob der Eintrag in der Liste gültige Daten enthält, ein Zeichen R, das anzeigt, ob die Vorbereitung der Transak­ tion abgeschlossen worden ist und die Transaktion bereit dazu ist, ausgeführt zu werden, ein Zeichen I, das anzeigt, ob die Vorbereitung der Transaktion gesperrt worden ist, bis zum Abschluß einer Eingabe/Ausgabe- oder Speicherzu­ griffsnachfrage, ein Zeichen G, das angibt, ob die Transak­ tion eine lokale oder globale Transaktion ist, und ein Zei­ chen P, das angibt, ob der Abschluß der Vorbereitung einer globalen Transaktion an den Koordinator berichtet worden ist. Die Zeichen G und B, die mit globalen Transaktionen verbunden sind, werden nachfolgend mit Bezug auf die Fig. 14 und 15 erläutert.

Mit der Liste 83 sind ein Kopfzeiger (head pointer) 108, ein Endezeiger 109 und ein Zeiger 110 für die Transaktion, die durchgeführt wird, verbunden. Der Kopfzeiger 108 hat z. B. einen negativen Wert, wenn die Liste leer ist, und hat ansonsten einen positiven Wert, der auf den Listeneintrag für die erste (höchste Priorität) Transaktion zeigt. Auf ähnliche Art und Weise hat der Endezeiger 109 einen negativen Wert, wenn die Liste leer ist, und hat ansonsten einen positiven Wert, der auf den letzten Eintrag in der Liste zeigt. Der Zeiger 110 auf die Transaktion, die ausgeführt wird, wird von dem Transaktionsplaner beim Schritt 101 der Fig. 5 eingesetzt, wenn auf einen Interrupt geantwortet wird. Insbesondere wird der Zeiger 110 dazu verwendet, um die jeweilige Kontextspeicherstelle für die unterbrochene Transaktion zu finden, wenn Schritt 101 durchgeführt wird.

Gemäß Fig. 5 überprüft der Transaktionsplaner beim Schritt 112, ob eine Transaktion für eine Ausführung bzw. Übertra­ gung bereit ist. Wenn das der Fall ist, ruft der Transak­ tionsplaner beim Schritt 113 den Koordinator (85) für die Ausführungsreihenfolge auf, die auszuführende Transaktion auszuwählen und eine Ausführungsreihenfolge mit möglichen Abbrüchen und Verzögerungen zu erzwingen. Wenn der Koordina­ tor für die Ausführungsreihenfolge beschließt, die Ausfüh­ rung nicht zu verzögern, dann überträgt der Systemelement- Manager (RM) beim Schritt 115 die Ergebnisse der Transak­ tion in den Zustandsspeicher.

Schließlich überprüft der Transaktionsplaner beim Schritt 116 die Transaktionsliste, um zu bestimmen, ob es eine nichtgesperrte Transaktion gibt, die noch nicht bereit ist. Wenn das der Fall ist, wählt der Transaktionsplaner beim Schritt 117 eine der nicht gesperrten Transaktionen aus, die noch nicht bereit ist. Um die Schritte 116 und 117 durchzuführen, überprüft der Transaktionsplaner z. B. zu­ erst, ob die Transaktionsliste leer ist, indem er testet, ob der Kopfzeiger 108 einen negativen Wert aufweist. Wenn der Kopfzeiger einen positiven Wert hat, dann überprüft der Transaktionsplaner die Zeichen L und I für die Transak­ tion am Anfang der Liste, um zu bestimmen, ob sie noch nicht bereit und nicht gesperrt ist. Wenn der erste Eintrag bereit ist oder gesperrt ist, dann überprüft der Transak­ tionsplaner den Endezeiger 109, um zu bestimmen ob das Ende der Liste erreicht worden ist. Wenn nicht, überprüft der Transaktionsplaner den Zeiger auf den nächsten Eintrag und führt die gleichen Schritte durch, bis entweder eine nicht­ gesperrte Transaktion, die noch nicht bereit ist, gefunden wird oder das Ende der Liste erreicht worden ist.

Wenn eine nicht gesperrte Transaktion, die noch nicht be­ reit bzw. fertig ist, ausgewählt worden ist, wird beim Schritt 118 der Kontext der ausgewählten Transaktion in dem Stapelspeicher plaziert. Bezüglich dieses Vorgangs wird darauf hingewiesen, daß, wenn eine Transaktion zuerst in der Transaktionsschlange plaziert ist, ein Anfangskontext für die Transaktion in dem jeweiligen Kontextspeicher für die unterbrochene Transaktion plaziert wird. Der Anfangskon­ text enthält z. B. einen Programmzählerwert, der auf den ersten Befehl in dem Programm für die Transaktion zeigt. Nach dem Schritt 118 wird eine Rückkehr von einem Interrupt (Unterbrechung) beim Schritt 119 durchgeführt, um die Aus­ führung von Instruktionen bzw. Befehlen in dem Programm für die ausgewählte Transaktion anzufangen oder fortzuset­ zen.

Fig. 7 zeigt ein spezielles Beispiel einer Datenstruktur zum Speichern des Seriengraphen (USG) für nicht entschie­ dene Transaktionen. Immer dann, wenn eine bestimmt Reihen­ folge für die Durchführung von in Konflikt stehenden Opera­ tionen in einem jeweiligen Paar von Transaktionen eingerich­ tet worden ist, wird die Reihenfolge der Durchführung der in Konflikt befindlichen Operationen in dem Seriengraphen für nicht entschiedene Transaktionen notiert. Wenn die Spei­ cherzugriffsoperationen, die von jeder Transaktion durchge­ führt werden, und die Speicherstellen dieser Speicherzu­ griffsoperationen zu einen Zeitpunkt bekannt sind, wenn eine Transaktion in der Liste plaziert bzw. untergebracht wird, dann ist es im Fall 1 der Fig. 3A zu diesem Zeitpunkt möglich, die Reihenfolge des Durchführens der in Konflikt stehenden Operationen zu bestimmen. In dieser Hinsicht wird darauf hingewiesen, daß für den Fall 1, wie er in Fig. 3A angegeben ist, Schreiboperationen wirksam sind, die zu dem Zeitpunkt der Transaktionsausführung (commitment) durchge­ führt werden. Außer in diesem bestimmten Fall wird die Rei­ henfolge der Durchführung von in Konflikt stehenden Opera­ tionen bestimmt, wenn eine zweite der in Konflikt stehenden Operationen für die Durchführung durch den Transaktionspla­ ner eingeplant wird und die Speicherstelle, auf die durch die in Konflikt stehende Operation zugegriffen wird, be­ stimmt wird.

Zu diesem Zeitpunkt wird das Vorhandensein eines Konflikts festgestellt, wie es weiter unten mit Bezug auf Fig. 11 erläutert wird, und die Reihenfolge der Durchführung wird in dem Seriengraphen für nicht entschiedene Transaktionen aufgezeichnet. Die Daten des Graphen der Fig. 7 sind in bildlicher Form in Fig. 8 dargestellt. Die Zeichen, die in der Datenstruktur nach Fig. 7 gesetzt sind, entsprechen den Kanten 131 in der bildlichen Darstellung der Fig. 8. Die Richtung einer Kante 131 gibt die Reihenfolge der Durchfüh­ rung der in Konflikt stehenden Operationen der Transaktio­ nen an. Wenn diese Reihenfolge der Durchführung einmal ein­ gerichtet ist, wird sie durch Abbrechen von Transaktionen oder Verzögern von Transaktionen oder zusätzlichen in Kon­ flikt stehenden Operationen erzwungen.

Das Erzwingen der Ausführungsreihenfolge durch Abbrechen von Transaktionen wird durch die Schritte 141 und 142 in Fig. 9 erläutert. Beim Schritt 141 wird eine für die Ausfüh­ rung fertige Transaktion ausgewählt. In Situationen, wo es eine Anzahl von fertigen Transaktionen bzw. bereiten Transaktionen gibt, wird eine bestimmte fertige Transaktion ausgewählt, z. B. durch Auswählen einer der ersten dieser Transaktionen in der Liste, indem vorgegebene Prioritäten, die mit den Transaktionen verbunden sind, verglichen werden oder in Antwort auf die Auswahl von einem Koordinator. Für die Liste 106 der Fig. 6 können z. B. globale Transaktio­ nen Priorität über lokale Transaktionen in dem Auswahlvor­ gang haben.

Beim Schritt 142 wird die Ausführungsreihenfolge durch Ab­ brechen der Transaktionen erzwungen, für die die Ausführung bzw. Übertragung im Gegensatz zur Ausführungsreihenfolge und der Ausführung der ausgewählten Transaktion steht. Bei der Ausführungsreihenfolge, die durch den Graphen in Fig. 8 dargestellt wird, werden z. B., wenn die Transaktion T₁ aus­ gewählt wird, die Transaktionen T₀ und T₃ abgebrochen, um die Ausführungsreihenfolge zu erzwingen. Das Abbrechen ei­ ner Transaktion umfaßt das Löschen der Ergebnisse jeder Transaktion. Bei lokalen Transaktionen kann eine Transak­ tion durch Zurücksetzen der Inhalte ihrer jeweiligen Kon­ textspeicher auf ihren Anfangskontext abgebrochen werden. Anders ausgedrückt wird der gegenwärtige Wert des Programm­ zählers für die Transaktion auf den Anfang des Programms für die Transaktion zurückgesetzt. Zudem müssen die Trans­ aktionsliste 106 und der Seriengraph 84 für nicht entschie­ dene Transaktionen neu initialisiert werden. Bei globalen Transaktionen wird eine abgebrochene Transaktion wenn über­ haupt von dem Koordinator neu gestartet. In diesen Fall wird die Transaktion vollständig aus der Transaktionsliste gestrichen bzw. entfernt.

Fig. 10 zeigt ein Flußdiagramm, das eine Prozedur 150 zum Auswählen einer für die Ausführung bereiten Transaktion zeigt, was oben stehend mit Bezug auf den Schritt 141 der Fig. 9 angerissen wurde. Beim ersten Schritt 151 der Fig. 10 wird die Transaktionsliste 106 mit dem Anfang bzw. Kopf der Liste beginnend nach der ersten bereiten Transak­ tion durchsucht. Zudem wird ein Ausführungszeichen (commit flag) zurückgenommen, das später in Fig. 10 verwendet wird. Als nächstes wird beim Schritt 152 die Anzahl der Teilneh­ mer in dem "Abbruchsatz" (abort set) der ausgewählten Trans­ aktionen gezählt. Mit Bezug auf den Seriengraphen 84 für nicht entschiedene Transaktionen der Fig. 8 enthält z. B. der Abbruchssatz jeder Transaktion in dem Graphen seine vorhergehenden Transaktionen. Anders ausgedrückt enthält der Abbruchsatz für die Transaktion T₁ die Transaktionen T₀ und T₃ und die Anzahl der Teilnehmer des Abbruchsatzes von T₁ ist zwei. Analog dazu haben die Transaktionen T₀ und T₄ keine Teilnehmer in ihren Abbruchsätzen. Geht man von der speziellen Datenstruktur der Fig. 7 aus, so werden die Teil­ nehmer eines Abbruchsatzes einer Transaktion durch die Kan­ tenzeichen (edge flags) bestimmt, die entlang einer Spalte der Datenstruktur gesetzt sind. Die Anzahl der Teilnehmer in dem Abbruchsatz wird durch Zählen der Anzahl der Zei­ chen, die in der entsprechenden Spalte für die Transaktion gesetzt sind, berechnet. Wenn der Abbruchsatz der ausgewähl­ ten Transaktion null ist (er hat keine Teilnehmer), was bei dem Schritt 153 überprüft wird, dann fährt die Ausführung beim Schritt 154 damit fort, möglicherweise die Ergebnisse der Transaktion in den Zustandsspeicher zu übertragen, was weiter unten mit Bezug auf die Fig. 15 für ein Transaktions­ verarbeitungssystem beschrieben wird, das lokale und globa­ le Transaktionen verarbeitet bzw. verwaltet.

Wenn der Abbruchsatz der ausgewählten Transaktion nicht Null ist, wird ein Versuch gemacht, die Ausführung der Transaktion zu verzögern, so daß die Anzahl der Teilnehmer in ihrem Abbruchsatz abnehmen kann. Diesbezüglich wird ange­ merkt, daß der Abbruchsatz einer bereitstehenden Transak­ tion nie zunehmen kann, aber abnehmen kann, da er jedesmal um Eins abnimmt bzw. verkleinert wird, wenn ein Teilnehmer ihres Abbruchsatzes ausgeführt bzw. eingegeben wird. Die Ausführung einer ausgewählten Transaktion sollte jedoch nicht unbestimmt lange verzögert werden, da ansonsten das System blockiert werden könnte. Die Verzögerung einer ausge­ wählten Transaktion wird deshalb beendet bzw. abgeschlos­ sen, wenn die Verzögerung eine vorgegebene Verzögerungszeit überschreitet. Beim Verarbeiten von globalen Transaktionen ist es auch wünschenswert, die Verzögerung in Antwort auf ein Abbruchsignal bzw. Beendungssignal von dem Koordinator zu beenden, wie weiter unten mit Bezug auf Fig. 15 beschrieben wird. Beim Schritt 157 der Fig. 10 wird die Verzögerungszeit als Differenz zwischen der gegenwärtigen Zeit und der Bereitzeit bzw. Fertigzeit für die Transaktion (die beim Schritt 103 der Fig. 5 gespeichert wurde) berechnet. Wenn die Verzögerungszeit eine vorgegebene Grenze bzw. einen vorgegebenen Grenzwert überschreitet, wie es im Schritt 158 überprüft wird, wird beim Schritt 159 ein Ausführungszeichen (commit flag) gesetzt.

Beim Schritt 160, wenn es zusätzliche fertige Transaktionen in der Transaktionsliste gibt, verzweigt die Ausführung zum Schritt 156, um die nächste fertige Transaktion zu bekommen und die Ausführung geht in der Schleife zurück zum Schritt 152. Ansonsten wird beim Schritt 161 das Ausführungszeichen überprüft und, wenn es nicht gesetzt wurde, dann fährt die Ausführung ohne eine Entscheidung fort, die ansonsten gemacht wird, um irgendeine der fertigen Transaktionen auszuführen. Ansonsten wird die fertige Transaktion mit der minimalen Anzahl von Teilnehmern in ihrem Abbruchsatz ausgewählt.

In Fig. 11 ist ein Flußdiagramm 170 einer Prozedur zum Bestimmen der Ausführungsreihenfolge von in Konflikt stehenden Komponentenoperationen der Transaktionen gezeigt. Die Prozedur 170 wird während der Vorbereitung einer Speicherzugriffsoperation, wie z. B. des Lesens oder Schreibens aufgerufen. Beim Schritt 171 wird die Adresse der Speicherzugriffsoperation bestimmt. Als nächstes wird beim Schritt 172 die Adresse mit der Adresse der früheren Operationen, die in Konflikt stehen könnte, verglichen. Dies wird durchgeführt, indem eine Liste der Adressen früherer Operationen für jede Transaktion in der Transaktionsliste durchsucht wird. Wenn die vorliegende Operation eine Leseoperation ist, kann die Leseoperation mit früheren Schreiboperationen in Konflikt stehen. Wenn die vorliegende Operation eine Schreiboperation ist, kann die Schreiboperation mit einer früheren Leseoperation (oder im Fall 2 der Fig. 3B, einer früheren Schreiboperation) in Konflikt stehen. Wenn es eine Adressübereinstimmung gibt, wie es beim Schritt 173 gete­ stet wird, wird beim Schritt 180 die gegenwärtige Reihen­ folge der Transaktion in dem Seriengraphen für nicht ent­ schiedene Transaktionen (84 in Fig. 7) aufgezeichnet. Insbe­ sonder treten Konflikte für den Fall 1 der Fig. 3A nur zwi­ schen einer Leseoperation und einer Schreiboperation auf und die Reihenfolge der Operationen ist Lesen, dann Schrei­ ben. Im Fall 2 der Fig. 3B muß die vorliegende Reihenfolge für die gegenwärtige Transaktion nach der vorhergehenden Transaktion durchgeführt werden. Beim Schritt 181 verzweigt die Ausführung zurück zum Schritt 172, wenn es zusätzliche frühere Speicherzugriffsoperationen zu überprüfen gibt. Ansonsten wird die Vorbereitung des Speicherzugriffs beim Schritt 177 durch Addieren der Adresse, die beim Schritt 171 festgelegt worden ist, zu einer Adressliste für Lese- und Schreiboperationen der gegenwärtigen Transaktion fortge­ setzt. Dann ist die Operation beim Schritt 178 vorbereitet oder wird beim Schritt 178 durchgeführt. Die Ausführung der Prozedur kehrt dann zu der Transaktion zurück.

Fig. 12 zeigt einen vergrößerten Seriengraphen für nicht entschiedene Transaktionen, in dem sich Kanten für Schreib/­ Lesekonflikte von Kanten anderer Konflikte unterscheiden. Ein solcher vergrößerter Graph kann in einer Datenstruktur ähnlich zu der Datenstruktur nach Fig. 7 gespeichert wer­ den, aber jede Kante wird durch ein Paar von Zeichen (flags) wiedergegeben, die aus einem ersten Zeichen, das jede Art von Konflikt angibt, und aus einem zweiten Zeichen beste­ hen, das einen Schreib/Lesekonflikt angibt. Der vergrößerte Graph der Fig. 12 wird eingesetzt, um kaskadierende Abbrü­ che durchzuführen, damit die Wiederherstellbarkeit in einem System, in dem eine zweite Transaktion die Schreibdaten der ersten Transaktion lesen kann, bevor die erste Transak­ tion ausgeführt wird, sichergestellt wird, wie zuvor mit Bezug auf Fig. 3B beschrieben worden ist. Eine Prozedur zum Durchführen eines kaskadierenden Abbruchs wird in dem Fluß­ diagramm 190 der Fig. 13 gezeigt. Man nehme z. B. an, daß T₅ als zur Ausführung fertige Transaktion ausgewählt wird. Um die Ausführungsreihenfolge zu erzwingen, müssen dann die Transaktionen T₃ und T₄ der Fig. 12 abgebrochen werden. Nimmt man jedoch an, daß das Transaktionsverarbeitungssy­ stem so arbeitet, wie es oben mit Bezug auf Fig. 3B be­ schrieben wurde, wird, wenn eine Transaktion abgebrochen wird, um die Ausführungsreihenfolge zu erzwingen, jede Transaktion, die Schreibdaten der abgebrochenen Transaktion gelesen hat, auch abgebrochen werden müssen. Aus dem vergrö­ ßerten Graphen der Fig. 12 ist zu sehen, daß, wenn die Transaktion T₄ abgebrochen wird, dann die Transaktion T₇ auch abgebrochen werden muß, da die Transaktion T₇ wegen des Schreib/Lesekonflikts zwischen den Transaktionen T₄ und T₇ auch negativ betroffen sein kann. Des weiteren, wenn die Transaktion T₇ abgebrochen wird, dann muß auch die Transaktion T₈ abgebrochen werden, da die Transaktion T₈ Daten gelesen hat, die durch die Transaktion T₇ geschrieben wurden.

Gemäß Fig. 13 wird bei der kaskadierenden Abbruchprozedur 190 zum Abbrechen der Transaktion T_x beim ersten Schritt 191 der vergrößerte Graph durchsucht, um alle Transaktionen T_y zu finden, die Daten gelesen haben, welche durch T_x ge­ schrieben worden sind. Dann wird bei Schritt 192 die Trans­ aktion T_x abgebrochen. In einem letzten Schritt 192 wird das Unterprogramm 190 der Fig. 13 rekursiv aufgerufen, um jede der Transaktionen T_y abzubrechen.

In der Fig. 14 wird ein Zustandsdiagramm eines Transaktions­ verarbeitungssystems gezeigt, das sowohl lokale als auch globale Transaktionen verarbeitet. Die lokalen Transaktionen werden z. B. von einem lokalen Benutzer 201 ausgegeben und die globalen Transaktionen werden von einem Koordinator 202 ausgegeben. In jedem Fall empfängt der Transaktionspla­ ner die Transaktionsnachfrage und setzt die Transaktions­ nachfrage in einen Eintrag der Transaktionsliste ein. Zu diesem Zeitpunkt wird die Transaktion als in Vorbereitung (preparation) befindlich bezeichnet. Der Transaktionsplaner transferiert schließlich die Ausführung zu der in Vorberei­ tung befindlichen Transaktion und die Transaktion wird aus­ geführt, bis sie entweder gesperrt wird oder fertig wird. Wie oben stehend in Verbindung mit Fig. 5 erläutert wurde, kann eine Transaktion sich selbst nach der Nachfrage nach einer Eingabe/Ausgabe- oder Speicheroperation sperren und nach der Beendigung einer Eingabe/Ausgabe- oder Speicherope­ ration wird die Transaktion freigegeben. Eine Transaktion, die entweder in Vorbereitung, gesperrt oder fertig bzw. abgeschlossen ist, kann abgebrochen werden, um eine Ausfüh­ rungsreihenfolge zu erzwingen.

Der Transaktionsplaner kann eine fertige lokale Transaktion ausführen. Um eine globale Synchronisation in einen verteil­ ten Transaktionsverabeitungssystem sicherzustellen, wird jedoch eine fertige globale Transaktion nur nach einer Quit­ tierung (handshake) mit dem Koordinator ausgeführt. Diese Quittierung stellt sicher, daß eine globale Transaktion nicht ausgeführt wird, bis alle Prozessoren, die zugewie­ sene Abschnitte der Transaktion verarbeiten, ebenfalls fer­ tig sind, oder bereit sind, ihre zugewiesenen Abschnitte der globalen Transaktion auszuführen bzw. zu übertragen. Deshalb, wenn der Transaktionsplaner den Zustand einer glo­ balen Transaktion von "in Vorbereitung befindlich" in den "fertig" Zustand ändert, gibt der Transaktionsplaner ein "Vorbereitet"-Signal an den Koordinator 202 ab.

Wenn der Koordinator 202 die "Vorbereitet"-Signale von al­ len Transaktionsplanern, die an einer Transaktion teilneh­ men, empfangen hat, sendet der Koordinator einen "Ausfüh­ rungs"-Befehl an den Transaktionsplaner zurück. Wenn der Koordinator jedoch nicht ein "Vorbereitet"-Signal von allen teilnehmenden Transaktionsplanern empfängt, kann der Koordi­ nator ein "Abbruch"-Signal an den Transaktionsplaner sen­ den. In Fig. 14 werden diese Quittierungssignale durch ge­ punktete Linien angegeben.

Wenn eine lokale Transaktion ausgeführt wird, entfernt der Transaktionsplaner die Transaktion aus der Liste und zeigt dem lokalen Benutzer an, daß die Transaktion abgeschlossen worden ist. Auf ähnliche Art und Weise, wenn eine globale Transaktion ausgeführt wird, entfernt der Transaktionspla­ ner die globale Transaktion von der Transaktionsliste und sendet ein Signal an den Koordinator, das angibt, daß die Transaktion abgeschlossen bzw. ausgeführt worden ist. Des weiteren, wenn eine globale Transaktion abgebrochen wurde, wird die globale Transaktion aus der Transaktionsliste und aus dem Seriengraphen für nicht entschiedene Transaktionen entfernt und der Transaktionsplaner sendet ein Signal an den Koordinator, um den Abbruch zu bestätigen. Für lokale Transaktionen kann es jedoch von Vorteil sein, die Vorberei­ tung der Transaktion erneut zu starten. In diesem Fall, ist es nur notwendig, den Anfangskontext der Transaktion erneut zu setzen, den Seriengraphen für nicht entschiedene Transak­ tionen zu löschen (clear) und den Zustand der Transaktion zurück in "Vorbereitung" zu setzen, indem die R- und I-Zei­ chen in dem Listeneintrag der Transaktion zurückgesetzt werden.

In Fig. 15 ist ein Flußdiagramm der Schritte, denen der Ausführungskoordinator zum Planen der Ausführung von globa­ len Transaktionen unterliegt. Die Prozedur der Fig. 10 kann z. B. entschieden haben, fortzufahren ohne eine Transaktion auszuführen. Beim Schritt 211 kann der Transaktionsplaner z. B. ein "Beende-Verzögerung"-Signal (terminate delay sig­ nal) von dem Koordinator empfangen haben. Dieses Signal kann ein spezielles Signal vom Koordinator sein oder es kann eine erneute Sendung einer vorher zugesendeten Transak­ tionsnachfrage sein. Wenn ein solches Signal empfangen wird, wird beim Schritt 212 das R-Zeichen für die Transak­ tion in der Transaktionsliste überprüft, um zu bestimmen, ob die globale Transaktion fertig ist. Wenn nicht, dann kann die globale Transaktion nicht ausgeführt werden. An­ sonsten werden dann die Teilnehmer des Abbruchsatzes für die Transaktion beim Schritt 213 überprüft, um zu bestim­ men, ob irgendeiner der Teilnehmer eine globale Transaktion mit einem gesetzten P-Zeichen ist. Der Schritt 213 wird auch bei globalen oder lokalen Transaktionen durchgeführt, für die die Prozedur nach Fig. 10 die Transaktion ausge­ wählt hat, nach Möglichkeit ausgeführt zu werden. Wenn der Abbruchsatz für die Transaktion, die für die Ausführung ausgewählt wurde, eine globale Transaktion mit einem geset­ zten P-Zeichen aufweist, kann die ausgewählte Transaktion nicht vor der globalen Transaktion mit dem gesetzten P-Zei­ chen ausgeführt werden. Deshalb wird die Ausführung in dem Transaktionsplaner fortgesetzt. Ansonsten verzweigt die Ausführung beim Schritt 211 in Abhängigkeit davon, ob die auszuführende Transaktion eine globale Transaktion ist oder nicht. Wenn sie eine globale Transaktion ist, kann sie nicht ausgeführt werden, bis der Transaktionsplaner ein Vorbereitungs-Anerkennungssignal an den Koordinator abgesen­ det hat und ein bestätigendes "Ausführungs"-Signal (commit Signal) empfangen hat. Bei einer globalen Transaktion wird deshalb das Vorbereitungs-Anerkennungs-Signal ("vorberei­ tet" in Fig. 14) an den Koordinator beim Schritt 216 gesen­ det, das P-Zeichen für die globale Transaktion in der Trans­ aktionsliste wird gesetzt und die Ausführung im Transak­ tionsplaner wird fortgesetzt. Ansonsten werden bei einer auszuführenden lokalen Transaktion beim Schritt 215 die Transaktionen in dem Abbruchsatz abgebrochen (und der "kas­ kadierende Abbruch" der Fig. 13 wird im Fall 2 der Fig. 3A verwendet) und die Ergebnisse der ausgewählten lokalen Transaktion werden zum Zustandsspeicher übertragen. Die Ausführung fährt dann im Transaktionsplaner fort.

Fig. 16 zeigt ein Flußdiagramm 220 zum Abarbeiten bzw. Ver­ walten vorbereiteter globaler Transaktionen in Antwort auf einen Ausführungs- oder Abbruch-Interrupt des Koordinators. Beim Schritt 221 verzweigt die Ausführung in Abhängigkeit davon, ob der Interrupt für eine Ausführung oder einen Ab­ bruch ist. Im Fall eines Abbruchs wird beim Schritt 222 die globale Transaktion abgebrochen, indem die Transaktion aus der Transaktionsliste entfernt wird und entsprechende Zeichen in dem Seriengraphen für unentschiedene Transaktio­ nen zurückgesetzt bzw. gelöscht werden. Schließlich wird beim Schritt 223 eine Anerkennung des Abbruchs zurück zum Koordinator gesendet und dann kehrt die Ausführungsprozedur vom Interrupt zurück.

Wenn beim Schritt 221 bestimmt worden ist, daß der Inter­ rupt für eine Ausführung war, dann werden beim Schritt 224 die Transaktionen im Abbruchsatz der ausgewählten globalen Transaktionen abgebrochen und die Ergebnisse der ausgewähl­ ten Transaktion werden in den Zustandsspeicher übertragen. Dann wird beim Schritt 223 eine Anerkennung bzw. Bestäti­ gung der Ausführung bzw. Übertragung zu dem Koordinator zurückgeschickt und die Ausführung der Prozedur kehrt vom Interrupt zurück.

Fig. 17 zeigt eine Ausführungsform der vorliegenden Erfin­ dung, in der ein Ausführungsreihenfolgenkoordinator (COCO = committment order coordinator) 151 in ein herkömmliches Transaktionsverarbeitungssystem eingefügt wird, das einen Transaktionsmanager (TM) 252 und einen Systemelement-Mana­ ger (RM = resource manager) 253 aufweist. Wie gezeigt, be­ steht der Ausführungsreihenfolgenkoordinator 251 aus einem Untersatz der Schnittstelle 254 zwischen dem Transaktionsma­ nager 252 und dem Systemelement-Manager 253. Der Ausfüh­ rungsreihenfolgenkoordinator überschneidet sich mit einem herkömmlichen Abschnitt 255 der Schnittstelle 254 und ist mit dem Systemelementmanager 253 via einer erweiterten Schnittstelle 256 verbunden, die einige zusätzliche Signale aufweist die individuell den Betrieb des Ausführungsreihen­ folgenkoordinators zugeordnet sind. In einem System mit verteilter Verarbeitung kann die Konfiguration nach Fig. 17 in jedem Knoten des Systems verwendet werden.

Es wird angenommen, daß der Systemelementmanager 253 die folgenden herkömmlichen Dienste zur Verfügung stellt:
R_VORBEREITE(T) (= R_PREPARE): Der TM zeigt dem RM an, die Transaktion T zu beenden. D. h., daß der RM keine weiteren Nachfragen oder externe Daten für die Transaktion T empfan­ gen wird;
R_AUSFÜHREN(T) (= R_COMMIT): Der TM zeigt dem RM an, die Transaktion T auszuführen. Eine Voraussetzung für das Aufru­ fen dieses Dienstes besteht darin, daß der RM vorhergehend die Vorbereitung der Transaktion anerkannt bzw. bestätigt hat (d. h., JA gewählt hat); und
R_ABBRUCH(T) (= R_ABORT): Der TM zeigt dem RM an (und mögli­ cherweise auch allen anderen RMs, die mit T zu tun haben), die Transaktion T abzubrechen.

Es wird auch angenommen, daß der Transaktionsmanager 252 die folgenden herkömmlichen Dienste zur Verfügung stellt:
T_FERTIG(T) (= T_READY): Der RM zeigt dem TM an, daß er die Verarbeitung der Transaktion T abgeschlossen hat und er wählt JA aus (d. h. er ist fertig, T zu übertragen oder abzu­ brechen gemäß der Notifikation von TM);
T_ABBRUCH(T) (= T_ABORT): Der RM zeigt dem TM an, daß er die Transaktion T abgebrochen hat (was in einem Abbruch von T durch alle beteiltigten RMs resultiert).

Wenn die TM-RM Schnittstelle 254 eingefügt ist, ruft der Ausführungsreihenfolgenkoordinator 251, und nicht der Sy­ stemelementmanager 253, direkt die T_FERTIG(T) und T_AB­ BRUCH(T) Dienste des Transaktionsmanagers 252 auf. Des wei­ teren empfängt der Ausführungsreihenfolgenkoordinator 251 anstatt des Systemelementmanagers direkt die Signale von dem Transaktionsmanager zum Verursachen der R_AUSFÜHRUNG(T) und R_ABBRUCH(T)-Dienste. Zur Erleichterung der Identifizie­ rung der Dienste in der nachfolgenden Beschreibung, werden die Dienste des Ausführungsreihenfolgenkoordinators bezüg­ lich dieser Signale als C_T_AUSFÜHRUNG(T) bzw. C_T_AB­ BRUCH(T) bezeichnet.

Das RM-COCO-Interface ist ein Untersatz der TM-COCO-Schnitt­ stelle. Insbesondere werden zusätzliche Dienste zum Auf­ rechterhalten des USG, der Datenstruktur des COCO, defi­ niert. Die Signale des RM, die vorher die herkömmlichen T_ FERTIG(T) und T_ABBRUCH(T) Dienste des Transaktionsmana­ gers aufgerufen haben, rufen jetzt die Dienste C_R_FERTIG 53452 00070 552 001000280000000200012000285915334100040 0002004216871 00004 53333 (T) und C_R_ABBRUCH(T) des Ausführungsreihenfolgenkoordina­ tors 251 auf. Der Ausführungsreihenfolgenkoordinator 251 wird auch durch den Systemelementmanager 253 aufgerufen, um die nachfolgenden zusätzlichen Dienste des Ausführungs­ reihenfolgenkoordinators durchzuführen:
C_R_ANFANG(T) (= C_R_BEGINN): Der RM zeigt dem COCO an, ei­ nen Knoten für T in dem USG einzurichten; und
C_R_KONFLIKT(T₁, T₂): Vor der Ausführung einer Operation von T₂, die einen Konflikt mit T₁ erzeugt, ruft der RM die­ sen Dienst auf, um dies dem COCO anzuzeigen. Wenn eine zuge­ ordnete Kante von T₁ nach T₂ noch nicht im USG existiert, wird sie erzeugt. Der tatsächliche Betrieb von T₂ wird durch den RM nur nach dem Empfangen eines Anerkennungssig­ nals von dem COCO ausgeführt, um sicherzustellen, daß der USG zu diesem Zeitpunkt aktualisiert ist. Der Systemelement­ manager 253 wird von dem Ausführungsreihenfolgenkoordinator 251 aufgerufen, um die ursprünglichen R_AUSFÜHRUNG(T) und R_ABBRUCH(T) Dienste durchzuführen. Der Systemelementmanager 253 wird ebenfalls von dem Ausführungsreihenfolgenkoordinator 251 aufgerufen, um den nachfolgenden zusätzlichen Dienst zur Verfügung zu stellen: R_KONFLIKT_ACK(T₁, T₂). Nach diesem Aufruf kann der RM die Operation von T₂ ausführen, die den entsprechenden Konflikt mit T₁ verursacht.

Unter Berücksichtigung der oben stehenden Definitionen der Aufrufe in dem System der Fig. 17 ist es offensichtlich, daß die Zustände des Systems auf die Aufrufe nach Fig. 18 reagieren. Die Aufrufe werden weiterhin durch den im Anhang III angegebenen PASCAL/SQL-basierenden Pseudocode, der auf dem Diagramm nach Fig. 18 beruht, erläutert.

In dem Pseudocode (Anhang III) werden gleichzeitige Aufrufe erlaubt, aber auch mehrere gleichzeitige Aufrufe des gleichen Dienstes. T_ERROR(T) und R_ERROR(T) sind Fehlernachricht-Aufrufe von TM bzw. RM, die eine fehlerhafte Aufrufsequenz anzeigen. Der Kernzustand (atomic state) der Transaktion wird als Fehlertyp zurückgegeben.

Der Anhang III ist im Deutschen Patentamt zur freien Einsicht hinterlegt und umfaßt 5 Seiten eines Programms für eine Datenverarbeitungsanlage, dessen Kommentare in deutscher Sprache abgefaßt sind. Es wird darauf hingewiesen, daß das Programm nach Anhang III zur Offenbarung der Erfindung gehört.

Der Ausführungsreihenfolgenkoordinator 251, der durch den Pseudocode nach Anhang III definiert wird, kann modifiziert werden, um eine Wiederherstellbarkeit des Ausgabeplans sicherzustellen. Der modifizierte Ausführungskoordinator wird als CORCO bezeichnet, der CORCO wird eingesetzt, wenn der schnittstellenbildende RM (253 in Fig. 17) die Wiederherstellbarkeit nicht sicherstellt und er noch dem Zustandsdiagramm nach Fig. 18 folgt. Der CORCO unterscheidet sich von dem o. a. Beispiel im Pseudocode durch Verwendung kaskadierender Abbrüche und durch die nachfolgenden zusätzlichen Modifikationen. Schreib/Lese-Konflikte werden durch die Kanten des USG wiedergegeben, wie es in Fig. 12 dargestellt ist. Wenn die Kante (T₁, T₂) einen wr-Konflikt (und möglicherweise einige weitere Konflikte) repräsentiert, hat das Boolean wr (T₁, T) den Wert wahr (= true), und keine JA-Wahl (YES vote) wird ausgegeben bei T₂, wenn wr (T₁, T₂) den Wert wahr (true) hat (um eine Verletzung der Wiederherstellbarkeit zu vermeiden). Des weiteren hat der Dienst C_R_KONFLIKT einen zusätzlichen Boolean Parameter, wr, um einen wr-Konflikt (C_R_KONFLIKT(T₁, T₂, wr) anzugeben. Weiterhin sind die Aufrufe des CORCO und seine VOTE-Prozedur Modifikationen des COCOs, die die oben aufgelisteten Unterschiede wiedergeben.

Die im Anhang IV angegebene rekursive Prozedur CASCADE (T) ruft T-Abort (T) und erzeugt zusätzliche T_ABORT-Aufrufe, wenn es erforderlich ist für die Aufrechterhaltung der Wiederherstellbarkeit.

Der Anhang IV ist im Deutschen Patentamt zur freien Einsicht hinterlegt; er umfaßt 5 Seiten eines Programms für eine Datenverarbeitungsanlage, dessen Kommentare in deutscher Sprache abgefaßt sind. Es wird ausdrücklich darauf hingewiesen, daß das Programm nach Anhang IV zur Offenbarung der vorliegenden Erfindung gehört.

Die Programme der Anhänge III und IV liegen auch in kompletter Originalversion im Anhang II vor, der ebenfalls zur freien Einsicht hinterlegt ist und 10 Seiten umfaßt.

Gemäß den oben stehenden Erläuterungen können die Komponen­ tenoperationen einer Anzahl von Transaktionen für die Aus­ führung in einer Art und Weise verteilt und eingeplant wer­ den, die für den Einsatz erhältlicher Rechnerverarbeitungs­ kapazitäten am effizientesten ist. Außerdem kann die Kon­ sistenz durch Erzwingen einer Ausführungsreihenfolge auf­ rechterhalten werden, in der Transaktionen in der gleichen Reihenfolge ausgeführt werden, mit der auch in Konflikt stehende Operationen durchgeführt werden. In einem verteil­ ten Transaktionsverarbeitungssystem stellt die Übereinstim­ mung mit einer Ausführungsreihenfolge die serielle Abarbei­ tung eines kombinierten (globalen) Planes sicher. Des weite­ ren wird die serielle Abarbeitung des kombinierten (globa­ len) Planes aufrechterhalten, während die Unabhängigkeit bzw. Autonomie jedes verteilten Prozessors aufrechterhalten wird und während herkömmliche Kernausführungsprotokolle (atomic commitment protocols) für die Koordination globaler Transaktionen verwendet werden.

Die Serienherstellbarkeit unter verteilten Transaktionen wird durch selektives Ausführen und Abbrechen oder Verzö­ gern von Transaktionen sichergestellt, um eine Reihenfolge der Ausführung zu erzwingen, die die gleiche ist wie eine Reihenfolge der Durchführung von in Konflikt stehenden Kom­ ponentenoperationen der Transaktionen. Eine erste Speicher­ zugriffsoperation einer ersten Transaktion steht z. B. in Konflikt mit einer zweiten Speicherzugriffsoperation, wenn sich die beiden Speicherzugriffsoperationen auf die gleiche Speicherstelle beziehen und zumindest eine der Operationen eine Schreiboperation ist. Das Transaktionsverarbeitungssy­ stem kann einer zweiten Transaktion gestatten, Daten zu lesen, die von einer Schreiboperation einer ersten Transak­ tion geschrieben wurden, bevor die erste Transaktion ausge­ führt wird. In diesem Fall wird, in Abhängigkeit von der jeweiligen Reihenfolge, in der die zwei in Konflikt stehen­ den Operationen auftreten, die Ausführungsreihenfolge er­ zwungen, möglicherweise durch Abbrechen einer der zwei Transaktionen, um sicherzustellen, daß die Ausführungsrei­ henfolge die gleiche ist wie die Reihenfolge der Operatio­ nen. Die Konflikte werden z. B. detektiert, wenn die Adres­ sen während einer Vorbereitungsphase der Transaktionen be­ stimmt werden. Die Komponentenoperationen können z. B. gemäß des am meisten effizienten Einsatzes der Computersystemkapa­ zitäten geplant werden. In einem Multiprozessorsystem, in dem ein globaler Koordinator mit einer Vielzahl von Transak­ tionsprozessoren mittels "Vorbereitungs"- und "Ausfüh­ rungs"-Kommandos kommuniziert, wird in dar Ausführungsrei­ henfolge auf Verzögerungsbestätigungen Bezug genommen, daß eine Transaktion "vorbereitet" worden ist, bis der "Ab­ bruchssatz" der Transaktion minimiert worden ist.

ANHANG I Definitionen und Nachweise für Eigenschaften des Ausfüh­ rungsordnens

Nachfolgend wird gezeigt, daß eine zeitliche Eigenschaft (history property), die als "Ausführungsreihenfolge" be­ zeichnet wird, das globale Problem der seriellen Abarbei­ tung löst. Insbesondere wird eine globale serielle Abar­ beitung garantiert, wenn jeder Systemelementmanager in ei­ nem verteilten Transaktionsverarbeitungssystem der "Ausfüh­ rungsreihenfolge" (commitment ordering) folgt und wenn sie Systemelementmanager "autonom" sind (d. h., sie koordinieren über Kernausführungsprotokolle (atomic commitment proto­ cols) und tauschen keine zusätzliche gleichzeitige Steuerin­ formation aus).

Definitionen

• 1. Eine Transaktion T_i ist eine teilweise Reihenfolge von Ereignissen. Die binäre, asymmetrische, transitive und irreflexive Beziehung, die die teilweise Reihenfolge bzw. Ordnung aufweist, wird mit "<_i" bezeichnet. Der Index i kann weggelassen werden, wenn der Identifizierer der Trans­ aktion aus dem Kontext bekannt ist. Die Ereignisse umfassen Lese- uns Schreiboperationen; r_i[x] bezeichnet, daß die Transaktion T_i das Datenfeld x gelesen hat, und w_i[x] be­ deutet, daß die Transaktion T_i das Datenfeld x geschrieben hat. Eine Transaktion weist auch das Ende-Ereignis einer Transaktion auf; e_i bedeutet, daß T_i abgeschlossen ist.

Axiome

• 1. Eine Transaktion T_i hat genau ein einziges Ereignis e_i. Ein Wert wird e_i wie folgt zugewiesen: e_i = c wenn und nur wenn die Transaktion ausgeführt wird; e_i = a wenn und nur wenn die Transaktion abgebrochen wird, e_i kann mit c_i bzw. a_i bezeichnet werden, wenn e_i = c oder e_i = a.
• 2. Für jede Operation p_i[x], die entweder r_i[x] oder w_i[x] ist, ist p_i[x] <_i e_i.

Definitionen

• 1. Zwei Operationen bezüglich eines Datenfelds x, p_i[x], q_i[x] stehen in Konflikt miteinander, wenn entweder p_i [x] gleich w_i[x] oder q_j[x] gleich w_j[x] ist.
• 2. Eine komplette History (complete history) H über einem Satz T von Transaktionen ist eine partielle Reihenfolge mit einer Beziehung <_H, die gemäß den nachfolgenden Axiomen 6, 7 und 8 definiert wird.

Axiome

• 1. Wenn T_i in T ist und Ereignis_a <_i Ereignis_b, dann ist Ereignis_a <_H Ereignis_b.
• 2. Wenn T_i und T_j in T sind, dann gilt für irgendwelche zwei in Konflikt stehenden Operationen p_i[x], q_j[x], daß entweder p_i[x] <_H q_j[x] oder q_j[x] <_H P_i[x].
• 3. Man nehme an, T_i und T_j sind Transaktionen in T und q_j [x] irgendeine Operation. Wenn w_i[x] <_H q_j[x], dann ist entweder e_i <_H q_j[x] oder q_j[x] <_H e_j. (Dieses Axiom lie­ fert eine einzigartige Definition der Semantik der History, da, wenn e_i = a, der Effekt von W_i[x] aufgehoben wird; d. h., daß das Lesen von x nach e_i im Lesen eines Wertes von x resultiert, der gerade vor w_i[x] existiert hat). (Be­ merke: Der Index H in <_H kann weggelassen werden, wenn H aus dem Kontext bekannt ist.)

Definitionen

• 1. Eine History (Ablauf, Reihenfolge) ist jedes Präfix einer kompletten History. Ein Präfix einer partiellen Ord­ nung P über einem Satz S ist eine partielle Reihe P' über einem Satz S' C S mit den folgenden Eigenschaften:
  Wenn b ∈ S' und a <_p b, dann auch a ∈ S'
  Wenn a, b ∈ S' dann a <_p b, wenn und nur wenn a <_p, b
• 2. Eine Transaktion T₂ ist in Konflikt mit einer Transak­ tion T₁, wenn und nur wenn für die zugehörigen in Konflikt stehenden Operationen q₂[x], p₁[x], daß p₁[x] < q₂[x]. (Merke, daß diese Definition asymmetrisch ist).
• 3. Wenn p₁[x] gleich w₁[x] und q₂[x] gleich w₂[x] ist, dann ist T₂ in einem ww-Konflikt (Schreib/Schreib-Konflikt) mit der Transaktion T₁.
• 4. Wenn p₁[x] gleich w₁[x] und q₂[x] gleich r₂[x], dann ist T₂ in einem wr-Konflikt (Schreib/Lesekonflikt) mit der Transaktion T₁.
• 5. Wenn p₁ ist r₁[x] und q₂[x] ist w₂[x], dann ist T₂ in einem rw-Konflikt (Lese/Schreib-Konflikt) mit der Transak­ tion T₁.
• 6. Es gibt eine Konfliktäquivalenz zwischen zwei Histo­ rien H und H' (die zwei sind konfliktäquivalent), wenn und nur wenn beide im gleichen Satz von Transaktionen T defi­ niert sind und aus den gleichen Transaktionsereignissen (für teilweise ausgeführte Transaktionen) bestehen und p_i [x] <_H q_j[x] wenn und nur wenn p_i[x] <_H, q_j[x] für jede in Konflikt stehende Operation p_i[x], q_j[x] jeder ausge­ führten Transaktion T_i bzw. T_j in T gilt (d. h., H und H' haben die gleichen Konflikte zwischen Operationen der ausge­ führten Transaktionen.
• 7. Eine History H bezüglich eines Transaktionssatzes T ist seriell, wenn und nur wenn für jeweils zwei Transak­ tionen T_i und T_j in T das folgende gilt:
  Wenn p_i[x] <_H q_j[y], dann gilt für irgendwelche weiteren Operationen s_i[u], t_j[v] in H s_i[u] <_H t_j[v] (d. h., alle Operationen von T_i gehen allen Operationen von T_j voran).
• 8. Eine History ist einreihbar, seriell anordenbar (SER; ist in SER), wenn und nur wenn sie konfliktäquivalent zu einer irgendwie seriellen History ist.
• 9. Seriengraph einer History H, SG(H) ist der gerichte­ te Graph SG(H) = (T, C), wobei T der Satz aller nicht abge­ brochenen (d. h. ausgeführten und unvollständigen) Transak­ tionen in H ist und C (ein Untersatz von T × T) ein Satz aus Kanten ist, die die Transaktionskonflikte wiedergeben, so daß es für irgendwelche zwei Transaktionen T₁, T₂, in T eine Kante von T₁ nach T₂ gibt, wenn und nur wenn T₂ in einem Konflikt mit T₁ ist. Der Seriengraph für ausgeführte Transaktionen (Commited Transaction Serializability Graph) einer History H, CSG(H), ist der Untergraph von SG(H) mit allen ausgeführten Transaktionen als Knoten und mit allen zugehörigen Kanten. Der Seriengraph für nicht entschiedene Transaktionen (Undecided Transactions Serializability Graph) einer History H, USG(H) ist der Untergraph von SG(H) mit all den nicht ausgeführten (d. h. unvollständigen) Trans­ aktionen als Knoten und mit all den zugehörigen Kanten.

Das Reihenanordnungs-Theorem: (Serializability theorem)

• 1. Eine History H ist in Reihe (SER) anordenbar, wenn und nur wenn CSG(H) zyklusfrei ist.

Definitionen

• 1. Eine History H ist behebbar (recoverable) (REC; ist in REC), wenn und nur wenn für irgendwelche zwei Transaktionen T₁, T₂, in H immer gilt, wenn T₂ ist in einem wr-Kon­ flikt mit T₁, daß T₂ nur ausgeführt wird, nachdem T₁ ausge­ führt worden ist. Formal geschrieben heißt das: (w₁[x] < r₂[x] und e₂ = c) bedeutet ((e₁ < e₂ und e₁ = c) oder (e₁ < r₂x und e₁ = a)).
• 2. Die History H vermeidet kaskadierende Abbrüche (cas­ cading aborts) (ACA; ist in ACA), wenn und nur wenn irgend­ eine Transaktion in H Daten liest, die von nur ausgeführten Transaktionen geschrieben worden sind. Man nehme an T₁, T₂ sind irgendwelche zwei Transaktionen in H. Der folgende Ausdruck ist eine formelmäßige Darstellung dieses Konzepts:
  w₁[x]r₂[x] bedeutet e₁ < r₂[x].
• 3. Man nehme an T₁, T₂ sind irgendwelche zwei Transaktio­ nen in H. H ist strikt (strict) (ST; ist in ST; hat die Striktheitseigenschaft), wenn und nur wenn W₁[x]p₂[x] bedeutet e₁ < p₂[x], wobei p₂[x] entweder r₂[x] oder w₂ [x] ist.

Theorem

• 1. REC ⊂ ACA ⊂ ST wobei ⊂ eine strikt einzuhaltende Bedin­ gung (containment) bezeichnet. (Dieses Theorem folgt unmit­ telbar aus den Definitionen).

Definitionen

• 1. Zwei Phasen Sperren (Two Phase Locking (2PL) ist ein Serieneinordnungsmechanismus, der zwei Typen von Sperren aufweist: Schreibsperren (write locks) und Lesesperren read locks). Es besteht darin, die Dauer der Transaktion in zwei Phasen einzuteilen: in der ersten Phase werden die Sperren aufgenommen (acquire), in der zweiten Phase werden die Sperren freigegeben bzw. gelöst (release).
• 2. Eine History ist in einem streng-strikten ZweiPhasen­ sperren (Strong-Strict Two-phase Locking (S-S2PL)), wenn und nur wenn für irgendeine in Konflikt stehende Operation p₁[x], q₂[x] der Transaktionen T₁ bzw. T₂ in H gilt, p₁[x] < q₂[x], was bedeutet e₁ < q₂[x]. (Bemerkung: eine History ist eine Zwei-Phasen-Sperrung, wenn sie durch den Zwei-Pha­ sen-Sperrmechanismus erzeugt werden kann. Eine strikte Zwei-Phasen-Sperrung erfordert, daß Schreibsperren, die in Namen einer Transaktion ausgegeben wurden, bis zu ihrem Ende nicht gelöst werden; Lesesperren können jedoch früher gelöst werden, und zwar am Ende der Phase 1 des Zwei-Pha­ sen-Sperrmechanismus. Die streng-strikte Zwei-PhasenSper­ rung erfordert, daß alle Sperren nicht gelöst werden, bevor die Transaktion abgeschlossen ist (wenn sie entweder ausge­ führt oder abgebrochen ist.) Eine streng-strikte ZweiPha­ sen-Sperrung blockiert irgendwelche in Konflikt stehende Operationen bezüglich eines Datenfelds, auf das von einer Transaktion zugegriffen wird, bis zum Ende der Transaktion.)
• 3. Ein Mechanismus blockiert, wenn er in einigen Situatio­ nen Ereignisse in einer Transaktion verzögert, bis gewisse Ereignisse in anderen Transaktionen auftreten.
• 4. Eine History-Eigenschaft ist inhärent blockierend, wenn sie nur durch einen Blockiermechanismus erzwungen wer­ den kann.
• 5. Eine History-Eigenschaft ist nicht inhärent blockie­ rend (non inherently blocking), wenn sie durch irgendeinen nicht blockierenden Mechanismus erzwungen werden kann. (Be­ merkung: Sowohl die Serienherstellbarkeit als auch die Wie­ derherstellbarkeit sind nicht inhärent blockierend, da sie immer sichergestellt werden können, indem eine verletzende Transaktion zu irgendeinem Zeitpunkt vor ihrem Ende abgebro­ chen wird. Diese Beobachtung ist die Basis für eine optimistische Gleichzeitigkeitssteuerung (optimistic con­ currency control), bei der Transaktionen ohne ein gegensei­ tiges Blockieren der jeweils anderen Ereignisse laufen und nur abgebrochen werden, wenn sie beendet sind, wenn eine Serienherstellbarkeit oder irgendeine andere gewünschte Eigenschaft durch sie verletzt wird. Zwei-Phasen-Sperren und ACA sind andererseits inhärent blockierend.)
• 6. Eine Transaktion wird entschieden (decided), wenn und nur wenn sie entweder abgebrochen oder ausgeführt wird; ansonsten ist sie nicht entschieden (undecided).
• 7. Eine nicht entschiedene Transaktion ist fertig (rea­ dy), wenn und nur wenn sie ihre Verarbeitung abgeschlossen hat und vorbereitet ist, entweder ausgeführt bzw. übertra­ gen oder abgebrochen zu werden; ansonsten ist sie aktiv.
• 8. Eine Transaktion ist nicht entschieden, wenn und nur wenn sie entweder fertig oder aktiv ist.

Ausführungsreihenfolge Definition

• 1. Eine History hat die Ausführungsreihenfolgeneigen­ schaft (Comitment Ordering (CO) property) (d. h., sie ist in CO), wenn und nur wenn für irgendwelche in Konflikt stehen­ de Operationen p₁[x], q₂[x] von ausgeführten Transaktionen T₁ bzw. T₂ p₁[x] < q₂[x] bedeutet e₁ < e₂. Formelmäßig ausge­ drückt (e₁ = c und e₂ = c und p₁[x] < q₂[x]) bedeutet e₁ < e₂.

Ausführungsreihenfolgentheorem (Commitment Ordering Theorem)

• 1. SER ⊂ CO (d. h., die Ausführungsreihenfolge bedeutet Serienherstellbarkeit.)
  Nachweis: Man nehme an, daß die History H eine CO ist und daß . . . → T_i → . . . → T_j → . . . ein (gerichteter) Weg im CSG (H) ist.
  Unter Verwendung der CO-Definition und der Induktion θ auf die Reihenfolge auf dem Pfad, läßt sich unmittelbar schließen, daß c_i < c_j ist. Man nehme nun an, daß H nicht in SER ist. Durch das Serienherstellbarkeits-Theorem (l. 18) (ohne Verlust an Allgemeingültigkeit) gibt es einen Zyklus T₁ → T₂ → . . . → T_n → T₁ im CSG (H). Man nehme an, daß T_i bzw. T_j T₁ bzw. T₂ sind (man betrachte ein geeignetes Prä­ fix des oben angegebenen Pfades). Das bedeutet durch die oben angegebene Beobachtung, daß c₁ < c₂ ist. Man nehme nun an, daß T_i bzw. T_j T₂ bzw. T₁ sind (man betrachte ein geeignetes Suffix bzw. eine geeignete Nachsilbe des oben angegebenen Pfades). Das bedeutet, daß c₂ < c₁ ist. Die zwei Implikationen widersprechen sich jedoch, da die Bezie­ hung "<" asymmetrisch ist. Deshalb ist CSG (H) azyklisch und H ist in SER durch das Serienherstellbarkeits-Theorem. Nun überprüfe man die folgende serienherstellbare nicht-CO- History, um zu folgern, ob die Bedingung strict ist: w₁[x] w₂[x]c₂c₁.

Definitionen

• 1. Ein Gleichzeitigkeitssteuermechanismus für Zeitmar­ kierungsordnen (TO) (Timestamp Ordering (TO) concurrency control mechanism) erzeugt die Serienherstellbarkeit und basiert auf einer Zeitmarkierung t_s (T_i) (eine reelle Zahl), die mit jeder Transaktion T_i verbunden ist; Zeitmar­ kierungen sind unterschiedlich.

Regel für Zeitmarkierungs-Reihenfolge

• 1. Für beliebige zwei in Konflikt stehende Operationen p₁[x], q₂[x] jeder ausgeführten Transaktion T₁ bzw. T₂ bedeutet t₂(T₁) < t₂(T₂), daß p₁[x] < q₂[x] ist. (Bemerkung: Zeitmarkierungsordnen ist nicht blockierend, da es durch Abbrechen von entweder T₁ oder T₂, nachdem alle ihre Operationen ausgegeben worden sind, erzwungen werden kann, und stellt die Basis für eine optimistische Gleich­ zeitigkeitssteuerung auf Basis des Zeitmarkierungsordnens (optimistic timestamp ordering based concurrency control) dar, aber auch die Basis für blockierende zeitmarkierungs­ ordnende Mechanismen.

Regel für blockierende Zeitmarkierungsordnung

• 1. Für beliebige zwei in Konflikt stehende Operationen p₁[x], q₂[x] irgendeiner Transaktion T₁ bzw. T₂ bedeu­ tet t₂(T₁) < t₂(T₂), daß p₁[x] < q₂[x]. (Merke: Diese Regel für blockierendes Zeitmarkierungsordnen erfordert, daß in Konflikt stehende Operationen entsprechend der Rei­ henfolge der Zeitmarkierungen unabhängig davon, ob die Transaktion ausgeführt wird oder nicht, verplant werden.)

Regel für zeitmarkiertes Ausführungsordnen

• 1. Für beliebige zwei ausgeführte Transaktionen T₁ bzw. T₂ mit zugehörigen in Konflikt stehenden Operationen bedeu­ tet t_s(T₁) < t_s(T₂), daß e₁ < e₂ ist. Formell: (e₁ = c und e₂ = c und (p₁[x], q₂[x]) stehen in Konflikt) und t_s(T₁) < t_s(T₂) bedeutet e₁ < e₂.

Theorem

• 1. Eine History hat die Ausführungsreihenfolge-Eigen­ schaft, wenn und nur wenn sie durch einen Mechanismus er­ zeugt wird, der sowohl der Regel für Zeitmarkierungsordnen (34) als auch der Regel für Zeitmarkierungsausführungsord­ nen (36) gehorcht. (Bemerkung: Dieses Theorem bedeutet, daß, wenn die Regel für Zeitmarkierungsausführungsordnen (TCO) durch irgendeinen Zeitmarkierungsordnungsmechanismus erzwungen wird, nur Historien mit der Ausführungsordnungs­ eigenschaft erzeugt werden. Die TCO-Regel kann einfach durch Verzögern von Ausführungsereignissen erzwungen wer­ den, wenn es notwendig ist, der Zeitmarkierungsordnung nach­ zukommen.)

Definitionen

• 1. Transaktionsende-Planer (TTS) (= transaction termina­ tion scheduler) ist ein Systemelement, das den Satz ferti­ ger Transaktionen überwacht und entscheidet, wann und wel­ che Transaktion ausgeführt bzw. abgebrochen wird. In einer Managerumgebung für viele Systemelemente nimmt dieses Sys­ temelement an Kernausführungsprozeduren (atomic commitment procedures) im Namen seines Systemelementmanagers teil und steuert (innerhalb des jeweiligen Systemelementmanagers) die Ausführung der Entscheidung, die über die Kernausfüh­ rung für jede relevante Transaktion erhalten wurde.
• 2. Ein Transaktionsende-Planer für Ausführungsordnen (COTTS) (= Commitment Ordering Transaction Terminating Scheduler) führt die folgende Prozedur oder eine hierzu äquivalente Prozedur aus:
  • a) Der COTTS hält einen Serienherstellbarkeitsgra­ phen bzw. Seriengraphen USC aller nicht entschiedenen Trans­ aktionen aufrecht. Jede neue Transaktion, die von dem RM verarbeitet wird, wird als neuer Knoten im USG wiedergege­ ben; jeder Konflikt zwischen Transaktionen im USG wird durch eine gerichtete Kante wiedergegeben (eine Kante zwi­ schen zwei Transaktionen kann somit mehrere Konflikte wie­ dergeben). USG(H) = (UT, C), wobei UT der Satz aller unent­ schiedenen Transaktionen in einer History H ist; und C (ein Untersatz von UT × UT) ist der Satz aus gerichteten Kanten zwischen Transaktionen in UT. Es gibt eine Kante von T₁ nach T₂, wenn und nur wenn T₂ in Konflikt mit T₁ ist. Der USG gibt alle Konflikte der Operationen bis zur Ausführung bzw. Übertragung wieder. Der Satz von Transaktionen, der als Ergebnis der Ausführung von T abgebrochen wurde (um eine zukünftige Verletzung der Ausführungsreihenfolge zu verhindern), wird wie nachfolgend definiert:
    ABORT_co(T) = {T'/T' → T ist in C}
  Der COTTS führt die folgenden Schritte iterativ bzw. schrittweise aus:
  • a) er selektiert jede fertige Transaktion (d. h. die ihre Verarbeitung abgeschlossen hat) T im USG (unter Verwendung irgendeines Kriteriums, möglicherweise der Prioritäten, die jeder Transaktion zugeordnet werden; eine Priorität kann dynamisch solange geändert werden, solange die Transaktion im USG ist) und führt sie aus;
  • b) er bricht alle Transaktionen in dem Satz ABORT_co(T) ab, d. h. alle Transaktionen (alle fertigen und aktiven) im USG, die eine Kante haben, die nach T geht; und (c) er entfernt jede entschiedene (decided) Transaktion (T) und die abgebrochenen Transaktionen) aus dem Graphen (sie gehö­ ren nicht zu USG gemäß der Definition).

Theorem

• 1. Der COTTS erzeugt Historyn mit der Ausführungsreihen­ folgeneigenschaft (CO).
  Nachweis: Der Nachweis wird durch Induktion bezüglich der Anzahl der Iterationen durch den COTTS erbracht, ausgehend von einer leeren Historie H₀ und einem leeren Graphen USG₀ = USG(H₀). H₀ ist eine CO. Man nehme an, daß die History H_n die nach der Iteration nb erzeugt wurde, eine CO ist. Der USG_n (in seiner UT-Komponente) enthält alle unentschiedenen Transaktionen in H_n. Jetzt wird eine zusätzliche Iteration durchgeführt, Zahl n + 1, und die Transaktion T₁ wird in USG durchgeführt (ohne Verlust an Allgemeingültigkeit). H_n+1 enthält alle Transaktionen in H_n und die neuen (nicht ent­ schiedenen) Transaktionen, die nach dem abschließenden Schritt n (und in USG_n+1 sind) erzeugt worden sind. Man teste die folgenden Fälle nach dem Abschließen der Itera­ tion n + 1:
  • a) Man lasse T₂, T₃ (ohne Verlust an Allgemeingültig­ keit) zwei ausgeführte Transaktionen in H_n sein. Wenn T₃ in Konflikt mit T₂ ist, dann c₂ < c₃, da H_n = CO ist, und zwar durch die Induktionshypothese.
  • b) c₂ < c₁, für jede (zuvor) ausgeführte Transaktion T₂ in H_n, mit der T₁ in Konflikt ist.
  Der oben stehende Fall schöpft alle möglichen Paare von in Konflikt stehenden ausgeführten Transaktionen in Hn1 aus. Deshalb ist Hn + 1 eine CO.

Bemerkung

Wenn eine Transaktion existiert, die nicht in einem Zyklus des USG vorkommt, dann existiert eine Trans­ aktion T mit keinen Kanten von irgendeiner anderen Trans­ aktion. T kann ohne Abbrechen irgendeiner anderen Trans­ aktion ausgeführt werden, da ABORT_co(T) leer ist. Wenn alle Transaktionen in USG auf Zyklen sind, muß zumindest eine Transaktion abgebrochen werden. Dies Situation scheint un­ gewöhnlich zu sein. In einer Umgebung mit vielen RMs, wenn der RM (TTS) nicht selbst die auszuführende Transaktion auswählt, sondern eine Nachfrage (über ein Kernausführungs­ protokoll (= atomic commitment protocol)) empfängt, um eine Transaktion T im USG auszuführen, müssen alle Transaktionen in ABORT_co(T), d. h. mit Kanten nach T, abgebrochen werden, wenn T ausgeführt wird (durch den COTTS). Der TTS kann wählen, daß T unmittelbar ausgeführt wird (die sogenannte nicht-blockierende Annäherung ohne Verzögerungen (= non- blocking without delays approach). Eine andere Annäherung bzw. Lösung (nicht blockierend mit Verzögerungen) besteht darin, die Ausführung für eine gegebene Zeitdauer zu ver­ zögern. Während der Verzögerung kann der Satz ABORT_co(T) kleiner oder leer werden. Wenn T im Fertigzustand ist, kann der Satz nicht größer werden bzw. zunehmen. Anstatt einer unmittelbaren Ausführung oder Verzögerung der Ausführung für eine gegebene Zeitdauer (die in einem Abbruch resultie­ ren kann) kann der TTS die Ausführung von T blockieren, bis alle Transaktionen im ABORT_co(T) entschieden sind. Wenn jedoch ein anderer RM in der Umgebung ebenfalls blockiert, kann das in einem globalen Stillstand resultieren.

Definitionen

• 1. Ein CORTTS ist ein COTTS, der Historien erzeugt, die sowohl CO als auch behebbar sind. Der CORTTS hält einen vergrößerten Serienherstellbarkeitsgraphen, wr-USG aufrecht:
  wr-USG(H) = (UT, C, C_wr), wobei
  UT der Satz aller unentschiedenen Transaktionen in der Historie H ist; und C ist der Satz der Kanten zwischen Transaktionen im UT. Es gibt eine C-Kante von T₁ nach T₂, wenn und nur wenn T nur in Nicht-wr-Konflikten mit T₁ ist. C_wr ist der Satz von Kanten zwischen Transaktionen in UT, der auch wr-Konflikte aufweisen kann. Es gibt eine C_wr-Kan­ te von T₁ nach T₂, wenn und nur wenn T₂ in wr-Konflikt mit T₁ ist (und möglicherweise ebenfalls in Konflikt mit anderen Typen). C und C_wr sind getrennt. Der Satz aus Transaktionen, die als Ergebnis der Ausführung von T abge­ brochen wurden (um zukünftige Verletzungen der Ausführungs­ ordnung zu verhindern), wird wie folgt definiert:
  ABORT_co(T) = {T'/T' → T ist in C oder C_wr}
  Die Definition von ABORT_co(T) hat hier die gleiche Semantik wie in dem jeweiligen Satz für COTTS. Der Satz der abge­ brochenen Transaktionen auf Grund der Wiederherstellbarkeit als Ergebnis einer abgebrochenen Transaktion T' wird wie folgt definiert:
  ABORT_REC(T*) = {T"/T' → T" ist in C_wr oder T''' → t" ist in C_wr, wobei T''' in ABORT_REC(T)}. Zu bemerken ist, daß die Definition rekursiv ist. Dies gibt die Natur kaskadierender Abbrüche gut wieder. Der CORTTS iteriert die folgenden Schritte: (a) er wählt irgendeine fertige Transaktion T im wr-USG aus, die keine hineinkommende C_wr- Kante hat (d. h. so, daß T nicht in ABORT_REC(T') für irgend­ eine Transaktion T' in ABORT_co(T) ist; damit die Notwendig­ keit eines späteren Abbruchs von T selbst vermieden wird, und führe sie aus; (b) unterbreche alle Transaktionen T' (sowohl die fertigen als auch die aktiven) in ABORT_co(T); (c) unterbreche alle Transaktionen T" (sowohl die fertigen als auch die aktiven) in ABORT_REC(T') für jedes T', das im vorhergehenden Schritt abgebrochen wurde (kaskadierende Abbrüche); und (d) entferne alle entschiedenen Transaktio­ nen (T und alle abgebrochenen Transaktionen) aus dem Gra­ phen. (Bemerkung: Während jeder Iteration soll wr-USG alle Operationskonflikte bis zur Ausführung wiedergeben.)

Theorem

• 1. Der CORTTS erzeugt CO, behebbare Historien Nachweis: Die erzeugten Historien sind eine CO durch das Theorem 40, da sich der CORTTS von dem COTTS nur bezüglich des Abbrechens zusätzlicher Transaktionen während jeder Iteration unterscheidet (und zwar wegen des Wiederherstell­ barkeitserfordernisses). Da alle Transaktionen, die die Wiederherstellbarkeit verletzen (Transaktionen in ABORT_REC(T')), für jede abgebrochene Transaktion T' in ABORT_co(T) während jeder Iteration abgebrochen werden (d. h. Transaktionen, die Daten lesen, welche durch eine abgebro­ chene Transaktion vor dem Abbruch geschrieben worden sind), sind die erzeugten Historien behebbar. (Bemerkung: Der CORTTS kann als nicht blockierend ohne Verzögerung, mit Verzögerung und als blockierender TTS mit vergleichbaren bzw. ähnlichen Ergebnissen implementiert werden, wie jene oben diskutierten in den Bemerkungen zu dem COTTS.)

Folgesätze

• 1. Ein COTTS erzeugt Historien, die serienherstellbar sind.
• 2. Ein CORTTS erzeugt Historien, die sowohl serienher­ stellbar als auch behebbar sind.
• 3. Nicht-blockierende Planer auf der Basis von COTTS und CORTTS erzeugen stillstandsfreie Ausführungen. (Bemer­ ke: Die TTS können mit irgendwelchen Systemelementzugriffs­ planern (RAS) (= resource access schedules) zum Planen von Systemelementzugriffsoperationen kombiniert werden. Wenn sowohl der TTS als auch der RAS nicht blockierend sind, dann ist auch der kombinierte Mechanismus nicht blockierend und deshalb stellt er Stillstandsfreiheit sicher. Eine Kom­ bination aus einem RAS und einem TTS kann den obenstehenden RAS ersetzen, wenn eine gewisse Filterung (durch einen TTS) erforderlich ist, um weitere History-Eigenschaften aufzu­ erlegen. In diesem Fall kann der filternde TTS nur dann eine Transaktion abbrechen. Aber es spielt keine Rolle, ob der RAS seriell ausgebildete Abläufe erzeugen kann oder nicht, da die obenstehenden COTTS Serienherstellbarkeit garantieren. Der kombinierte Mechanismus kann wie folgt ausgeführt werden: zuerst werden die Transaktionen durch den RAS (oder durch einen RAS mit einem TTS) kontrolliert. Die nicht abgebrochenen, fertigen Transaktionen werden von dem COTTS als auszuführende Kandidaten betrachtet und Trans­ aktionen werden abgebrochen, wenn sie die Bedingungen des COTTS verletzen. Man bemerke, daß, wenn der obenstehende Planer auf S-S2PL beruht, dann der USG des zugehörigen COTTS keinerlei Kanten aufweist. Das bedeutet, daß keine Abbrüche durch den COTTS benötigt werden, wie man erwarten kann, und ein COTTS unnötig ist. Das ist eine extremer Fall. Andere Planertypen können andere Eigenschaften der zugehörigen USGs mit sich bringen, um gewünschte Planungs­ muster und Systemeigenschaften bzw. Verhalten zu ermögli­ chen, und zwar gemäß der Natur der auftretenden Transak­ tionen. Es ist auch darauf hinzuweisen, daß, wenn der kombi­ nierte CC-Mechanismus die Wiederherstellbarkeitseigenschaft garantiert, der COTTS ausreichend ist (es besteht keine Notwendigkeit für den CORTTS, da die Wiederherstellbarkeit gegeben ist). Wenn der Planer auf Zeitmarkierungsordnen (TO) basiert und CO erwünscht ist, kann ein Vorteil aus den existierenden Datenstrukturen gezogen werden, und weniger aus dem unabhängigen Implementieren der USGs. In diesem Fall kann CO erhalten werden, indem die Regel für Ausfüh­ rungsordnen mit Zeitmarkierung erzwungen wird.

Definitionen

• 1. Eine Umgebung (environment) weist ein System mit ver­ teilten Diensten auf, das eine Vielzahl von Systemelement­ managern (RMs) aufweist, wobei eine Transaktion irgendeinen Untersatz von teilnehmenden RMs überspannen kann. Jeder RM in einer Umgebung hat einen Identifizierer (z. B. RM 2). Ereignisse werden durch den Identifizierer der Transaktion und durch den Identifizierer des RMs eingestuft (z. B. w_3,2 [x] bedeutet eine Schreiboperation eines Datenfelds x durch einen RM 2 im Namen der Transaktion T₃).

Axiom

• 1. Wenn P_i,j[x], q_k,l[y], j ≠ l Operationen sind (je­ weils durch RMs j, l), dann ist x ≠ y; d. h. diese Operation können nicht in Konflikt stehen.

Definitionen

• 1. Eine globale Transaktion T_i besteht aus einem oder mehreren lokalen Untertransaktionen (subtransactions). Eine lokale Untertransaktion T_i,j greift auf alle Daten unter der Steuerung eines RMj zu, die T_i zum Zugreifen benötigt, und nur auf diese Datenfelder (d. h. alle ihre Ereignisse werden mit j bezeichnet bzw. klassifiziert). Eine lokale Untertransaktion gehorcht der Definition einer Transaktion. Eine lokale Untertransaktion hat die Zustände einer Transak­ tion.
• 2. Eine lokale History wird durch einen einzelnen RM erzeugt und über den Satz ihrer lokalen Untertransaktionen definiert. Eine lokale History gehorcht der Definition ei­ ner History in Abschnitt 2. H_i ist eine History, die von einem RMi mit einer Beziehung <_Hi erzeugt wurde. (Bemerke: Es wird angenommen, daß ein Kernausführungsprotokoll (AC) (atomic commitment protocol) angewendet wird, um die Kern­ eigenschaft (atomicity) in der verteilten Umgebung sicherzu­ stellen.)
• 3. Ein AC-Protokoll implementiert das folgende generel­ le Schema immer, wenn über eine Transaktion entschieden wird: jeder teilnehmende RM wählt entweder "ja" oder "nein", (aber nicht beide) nachdem die zugehörige lokale Untertrans­ aktion den Fertig-Zustand erreicht hat, oder wählt "nein", wenn sie nicht in der Lage ist, den "Fertig-Zustand" zu erreichen. Die Transaktion wird von allen RMs ausgeführt, wenn und nur wenn alle "ja" gewählt haben. Ansonsten wird sie von allen RMs abgebrochen. (Bemerkungen: 2PC ist ein spezieller Fall der AC. Ausfall- und Wiederherstellungsaus­ gaben werden hier nicht behandelt.) Die Tatsache, daß AC verwendet wird, legt die Vermutung nahe, daß eine verteilte Transaktion ein einziges Ausführungsereignis hat (obwohl dies in der Wirklichkeit nicht immer sichergestellt ist). Dies ist jedoch für Abbrüche nicht gegeben.
  Beispiel: die folgenden zwei Transaktionen greifen beide auf Datenfelder bzw. Datensätze x und y zu. x, y sind unter der Kontrolle des RMs 1 bzw. des RMs 2. T₁ und T₂ und ihre lokalen Transaktionen sind die folgenden:
  RM1 T_1,1 : r_1,1[x]c₁ T_2,1 : w_2,1[x]c₂
  RM2 T_1,2 : r_1,2[y]c₁ T_2,2 : w_2,2[y]c₂
  T₁ T₂
  Die RMs erzeugen die nachfolgenden (lokalen) Historien H₁ und H₂:
  RM1: H₁ r_1,1[x]w_2,1[x]c₂c₁
  RM2: H₂ w_2,2[x]c₂r_1,2[y]c₁
  Man bemerke, daß die History H₁ die Ausführungsreihenfolge verletzt, was in einer (globalen) Serienherstellbarkeits­ verletzung resultiert. Die jeweilige globale History H wird durch die folgenden Beziehungen der Reihenfolge beschrieben:
  r_1,1[x] < w_2,1[x] < c₂ < r_1,2[y] < c₁ w_2,2[y] < c₂
  
• 4. Für jede History-Eigenschaft X ist eine (globale) History H in Lokal-X (ist lokales X), wenn und nur wenn für jedes RMi in der Umgebung H_i (die History von RMi) in X ist (ist X).

Theorem

• 1. Eine History ist in X (globales X), wenn und nur wenn sie in Lokal-X ist (d. h. Lokal-X = X), wobei X irgendeine der nachfolgenden Eigenschaften ist: REC, ACA, ST, CO, S-S2PL.
  Nachweis: folgt aus der Definition von Lokal-X, Axiom 47, und den Definitionen von REC, ACA, ST, CO und S-S2PL.

Theorem

• 1. In Lokal-X zu sein, bedeutet nicht, daß eine History in X ist (d. h. Lokal-X ⊂ x), wobei X eine der nachfolgenden Eigenschaften ist: SER, 2PL, S2PL
  Nachweis: Man lasse H die History sein, wie im obenstehen­ den Beispiel. Die History H ist Lokal-SER, Lokal-2PL und ein Lokal-S2PL, da sowohl H₁ und H₂ in SER, 2PL und S2PL sind. H ist jedoch nicht in SER, 2PL oder S2PL. CSC (H) hat einen Zyklus, so daß H nicht in SER ist. Wenn S in 2PL ist, ist es auch in SER und es liegt ein Widerspruch vor.

Theorem

• 1. SER ⊂ Lokal-CO. Anders ausgedrückt, wenn eine Histo­ ry in Lokal-CO ist, dann ist sie global seriell angeord­ net. Dieses Theorem folgt aus dem Ausführungsreihenfolge- Theorem und dem Theorem 52. (Bemerke: Lokal-CO kann durch RMs aufrechterhalten werden, indem irgendwelche Typen von CO-Mechanismen verwendet werden.)

Definition

• 1. Eine dauerhafte Risikotransaktion (permanent risk transaction (PR)) ist eine Transaktion, die eine potentiel­ le Verletzung der Serieneigenschaft verursacht, wenn sie ausgeführt wird, und in dieser Situation für immer bleibt. Die PR-Eigenschaft bezieht sich auf den Systemelementma­ nager. Das obenstehende Erfordernis bedeutet, daß jeder RM in der Umgebung die folgende Ausführungsstrategie (CS) (= commitment strategy): ausgehend von einer History mit keinen entschiedenen Transaktionen, wird jede fertige Trans­ aktion ausgeführt (für gewöhnlich wird der RM über ein AC- Protokoll nachgefragt, um eine Transaktion auszuführen). Jede andere Transaktion, die ein PR ist, wird abgebrochen. (Das Geheimaxiom (hidden axiom) wird hier angenommen, daß Systemelemente nicht unnötigerweise gehalten werden. An­ sonsten können PR-Transaktionen markiert werden und für immer nicht entschieden bleiben.) Dann wird eine andere (irgendeine) fertige Transaktion, die keine Verletzung der Serieneigenschaft verursacht, ausgeführt. Wieder werden alle PR-Transaktionen abgebrochen, usw.

Theorem

• 1. Wenn nur eine Information über lokale Serieneigen­ schaft erhältlich für jeden RM in der Umgebung ist und wenn Kernausführung (atomic commitment) angewendet wird, dann ist CS eine notwendige Strategie für jeden RM, um eine glo­ bale Serieneigenschaft sicherzustellen. CS erzeugt Lokal- CO-Historien (globale Historien in Lokal-CO).
  Nachweis: Das Serieneigenschafts-Theorem bedeutet, daß der Serieneigenschaftsgraph all die notwendigen Informationen über die Serieneigenschaft bzw. Serienherstellbarkeit zur Verfügung stellt. Unter der Annahme, daß jeder RM, oder besser RMi, seinen lokalen Serieneigenschaftsgraphen SG_i "weiß" (er enthält alle ausgeführten und nicht entschiede­ nen Transaktionen) und seine Untergraphen CSG_i (die nur ausgeführte Transaktionen enthalten) und USG_i (der alle nicht entschiedenen Transaktionen enthält). Es wird auch angenommen (beruhend auf AC), daß jeder RM eine Transaktion ausgeführt hat, wenn und nur wenn er "Ja" gewählt (voted) hat und "weiß", daß alle anderen RMs, die an einer Transak­ tion teilnehmen, "Ja" gewählt haben, und sie schließlich ausgeführt hat. Das Ziel für jeden RM ist es, einen zyklus­ freien (globalen) CSG sicherzustellen (einen Seriengraphen mit ausgeführten Transaktionen), in dem jede Aktion vermie­ den wird, die einen globalen Zyklus (lokale Zyklen im CSG_i werden durch den RMi beseitigt) erzeugt. Zuerst ist CS trivialerweise notwendig aus den folgenden Gründen: da eine PR-Transaktion für immer PR bleibt (wegen Definition), kann sie nicht ausgeführt werden und muß abgebrochen werden, um Systemelemente freizugeben. Auf der anderen Seite kann jede fertige Transaktion, die keine Verletzung der Serieneigen­ schaft verursachen kann, ausgeführt werden. Es ist nun not­ wendig, permanente Risikotransaktionen (PR) zu identifizie­ ren, während CS implementiert wird. Man kann zeigen, daß dies bedeutet, daß jeder RM als COTTS arbeitet. Jeder RM implementiert CS wie folgt:
  • a) Basisstufe: Man nehme an, daß CSG_i keine Trans­ aktion enthält. Führe jede fertige Transaktion T aus. Nehme an, daß vor dem Ausführen von T eine Kante T' → T in USG_i vorhanden ist. Es ist möglich, daß es eine Kante T → T' in einigen USG_j von einigen RMj gibt, wobei j ≠ i ist, aber RMi kann dies nicht überprüfen. Das bedeutet, daß das spätere Ausführen von T' einen Zyklus in CSG verursa­ chen kann. Da das Ausführen von T nicht rückgängig gemacht werden kann (siehe Transaktionszustandseinschwingen bzw. Übergänge in Abschnitt 3), kann kein Ereignis diese Situa­ tion ändern. Deshalb ist T' eine PR und RMi muß sie abbre­ chen.
  • b) Induktive Stufe: Angenommen, daß CSG_i zumindest eine Transaktion enthält. Es kann gezeigt werden, daß keine fertige Transaktion eine Verletzung der Serieneigenschaft verursachen kann, wenn sie ausgeführt wird, und deshalb kann sie ausgeführt werden (vorausgesetzt, daß eine Überein­ stimmung für die Ausführung durch alle teilnehmenden RMs über den AC erreicht wird): führe jede fertige Transaktion T aus. Überprüfe jede vorher ausgeführte Transaktion T". Es ist unmöglich, einen Pfad T → . . . → T" in CSG_i oder in CSG_j für jeden RMj, wobei j ≠ i ist, zu haben, da, wenn dieser Pfad in der Stufe existieren würde, wenn T" ausge­ führt wird, er während dieser Stufe abgetrennt werden wür­ de, wenn alle Transaktionen mit Kanten nach T" abgeblockt werden (unter Einsatz der Argumente, die für die Basisstufe oben gegeben wurden), und da keine hinzukommenden Kanten nach T" erzeugt werden hätten können, nachdem T" ausge­ führt worden ist. Deshalb kann nur ein Pfad T" → . . . → T in CSG_i oder in CSG_j für jeden RMj existieren, wobei j ≠ i ist. D. h., daß kein Zyklus in CSG durch T und T" erzeugt werden kann und daß kein T" abgebrochen zu werden braucht (was die Strategie verletzen würde). Nachfolgend wird ir­ gendeine nicht entschiedene Transaktion T' (in USG_i) über­ prüft. Man nehme an, daß vor dem Ausführen von T eine Kante T' → T in USG_i vorhanden ist. Wenn wiederum die Argumente für die Basisstufe verwendet werden, ist T' eine PR und der RMi muß sie abbrechen (indem er "Nein" über AC wählt). Wenn es keine Kante von T' nach T gibt, dann wird auch kei­ ne Entscheidung betreffend T' in dieser Stufe ausgeführt.
  Die obenstehenden Argumente stellen sicher, daß keine fer­ tige Transaktion eine Verletzung der Serieneigenschaft ver­ ursachen kann, wenn sie zu Anfang der induktiven Stufe aus­ geführt wird, wie angenommen wurde, und deshalb konnte (ir­ gendeine fertige Transaktion) T ausgeführt werden.
  In der CS-Implementation oben werden alle PR-Transaktionen identifiziert und in jeder Stufe abgebrochen. Durch Über­ prüfen dieser Implementation konnte festgestellt werden, daß sie als ein COTTS funktioniert. Deshalb erzeugt jeder RM wegen des Theorems 40 eine CO-History und die erzeugte (globale) History ist eine Lokal-CO (in Lokal-CO). Die ein­ zig mögliche Abweichung von dieser obenstehenden Implementa­ tion ist durch Abbrechen zusätzlicher Transaktionen in je­ der Stufe gegeben. Eine solche Abweichung hält noch die erzeugte History in Lokal-CO.

Schlußfolgerung

• 1. Wenn die RMs eine Gleichzeitigkeitskontrolle nur mit­ tels Kernausführung (atomic commitment) koordinieren, dann ist ein lokales Ausführungsordnen (local commitment order­ ing) eine notwendige und ausreichende Bedingung für eine (globale) Serienherstellung. Diese Schlußfolgerung folgt aus den Theoremen 52, 55 und 56.

Schlußfolgerung

• 1. Wenn die RMs eine gleichzeitige Kontrolle nur über eine Kernausführung steuern, dann sind lokales Ausführungs­ ordnen und lokales Wiederherstellen eine notwendige und ausreichende Bedingung für eine (globale) Serienherstellbar­ keit und Wiederherstellbarkeit. Diese Schlußfolgerung folgt aus dem Theorem 52.
• 2. Ein globaler Stillstand ist ein Stillstand, der durch ein gegenseitiges Blockieren von zwei oder mehreren loka­ len Untertransaktionen in zumindest zwei unterschiedlichen Transaktionen von zumindest zwei unterschiedlichen RMs ver­ ursacht wird. (Bemerkungen: Da ein Ausführungsordnen nicht inhärent blockierend ist, kann es in einer nicht blockieren­ den Art und Weise z. B. durch Abbrüche oder durch Abbrüche nach Verzögerungen implementiert bzw. bewerkstelligt wer­ den. Wenn die Planer aller RMs in der Umgebung nicht bloc­ kierend sind (mit der Ausnahme eines einzigen, der bloc­ kierend sein kann), sind die Ausführungen stillstandsfrei.
  Einen anderen Weg für die Implementierung von Ausführungs­ ordnen besteht in der Verwendung von blockierenden CO-Be­ stätigern (blocking CO certifiers) (CO-Planern mit nicht blockierenden RAS und blockierenden TTS). Wenn die Planer für alle RMs Bestätiger sind und zumindest zwei davon bloc­ kierend sind, können globale Stillstände auftreten (sogar dann, wenn jeder RM seinen eigenen Stillstand löst bzw. auflöst). In diesem Fall sind alle Transaktionen, die mit dem Stillstand beteiligt sind, in einem Fertig-Zustand. Diese Tatsache erlaubt es, Stillstände (deadlocks) während einer Kernausführung (atomic commitment) aufzulösen.
  Wenn Planer von zwei oder mehreren RMs blockieren, wobei einer zumindest einen blockierenden RAS hat (z. B. S-S2PL. oder CO, BTO basierend), dann können auch aktive Transak­ tionen an einem globalen Stillstand beteiligt sein. In die­ sem Fall sind Nachrichten über Kernausführungen nicht aus­ reichend für eine Stillstandsauflösung und zusätzliche Nach­ richten, die das Vorhandensein von Blöcken bzw. Blockierun­ gen signalisieren, sind erforderlich (möglicherweise aufge­ setzt (piggy-backed) auf AC-Nachrichten anderer Transak­ tionen).

Schlußfolgerung

Ausführungsordnen stellt einen Weg zum Erreichen einer glo­ balen Serienherstellbarkeit zur Verfügung, und das auch durch stillstandsfreie Mechanismen. Das erlaubt einen Kom­ promiß zwischen blockierenden Techniken, die Stillständen unterworfen sind, und nicht blockierenden Implementationen, die stillstandsfrei sind aber kaskadierenden Abbrüchen un­ terzogen sind. Um eine Serienherstellbarkeit sicherzustel­ len, sind keine Dienste, aber eine Kernausführung für die Koordination des Transaktionsmanagements durch RMs notwen­ dig, wenn jeder RM ein Ausführungsordnen (commitment order­ ing) unterstützt. Ein Ausführungsordnen ist für eine globa­ le Serienherstellbarkeit jedoch notwendig, wenn nur eine Kernausführung für die RM-Koordination verwendet wird.

Claims (19)

1. Computergesteuertes Verfahren zur Ablaufsteuerung von Transaktionen in einem Datenverarbeitungssystem, das die folgenden Verfahrensschritte aufweist:

• 1. Beginn der Vorbereitung von Ergebnissen der Transaktionen durch Durchführen von Operationen der Transaktionen;
• 2. Bestätigen von Transaktionen durch Einschreiben der Ergebnisse der Operationen der Transaktionen in einen Zustandsspeicher, wobei das Verfahren ferner aufweist:
• 3. Prüfung, ob Speicherzugriffskonflikte zwischen den Transaktionen bestehen, wobei nicht alle Transaktionen Speicherzugriffskonflikte haben, und, wenn bei der Prüfung auf Speicherzugriffskonflikte festgestellt wird, daß bei einer der Transaktionen eine erste Operation mit einer zweiten Operation bei einer anderen Transaktion in Konflikt steht, Aufzeichnen einer Reihenfolge der Durchführung der ersten und zweiten in Konflikt stehenden Operation in einem Speicher des Datenverarbeitungssystems;
• 4. nachdem diese Transaktionen mit der ersten bzw. zweiten in Konflikt stehenden Operation sowie deren Ergebnisse vorbereitet wurden, so daß jede der beiden Transaktionen bereit ist, bestätigt zu werden, Auswahl einer der beiden zu bestätigenden Transaktionen und dadurch Kennzeichnung dieser Transaktion als ausgewählte Transaktion und Bestimmung eines Satzes von Abbruchtrans­ aktionen, bei denen eine Bestätigung nach der Bestätigung der ausgewählten Transaktion im Widerspruch zu der im Speicher des Datenverarbeitungssystems gespeicherten Durchführungsreihen­ folge stehen würde, so daß dieser Satz von Abbruchtransaktionen alle noch nicht bestätigten oder nicht abgebrochenen Transaktionen einschließt, bei denen eine Operation durchgeführt wurde, die in Konflikt mit einer später durchgeführten Operation in der ausgewählten Transaktion steht, und, in Abhängigkeit von der Auswahl der ausgewählten Transaktion,
• 5. Eingeben (Einschreiben) der Ergebnisse der ausgewählten Transaktion in den Zustandsspeicher und
• 6. Abbrechen aller Transaktionen im Satz von Abbruchtransaktionen, wobei der Satz von Abbruchtransaktionen mindestens eine Transaktion einschließt, deren Ergebnisse bereits vorbereitet und zur Ausführung fertig sind und die eine durchgeführte Operation hat, die mit einer später durchgeführten Operation in der ausgewählten Transaktion in Konflikt steht.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Schritt des Eingebens in den Zustandsspeicher das Aktualisieren einer Datenbank umfaßt.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Schritt des Eingebens in den Zustandsspeicher das Ändern des Speicherzustands eines Datenobjekts enthält.

4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die ausgewählte Transaktion aus den Transaktionen durch Vergleichen vorgegebener Prioritäten ausgewählt wird, die den Transaktionen zugewiesen sind.

5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die ausgewählte Transaktion aus den Transaktionen auf der Basis einer Reihenfolge der Transaktionen in einer Liste ausgewählt wird.

6. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Schritt des Auswählens der ausgewählten Transaktion in Reaktion auf ein Ausführungskommando von einem Koordinator durchgeführt wird.

7. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die ausgewählte Transaktion aus den Transaktionen ausgewählt wird, um die Anzahl der Transaktionen zu minimieren, die im Schritt ii) abgebrochen werden.

8. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß es umfaßt:
Empfangen einer Anforderung von einem Koordinator zur Spezifikation einer vorzubereitenden Transaktion, um dadurch eine spezifizierte Transaktion zu identifizieren, wobei die Vorbereitung von Ergebnissen für die spezifizierte Transaktion in Schritt a1) begonnen wird, und wobei das Verfahren ferner den Schritt einer Verzögerung der Bestätigung der Beendigung der Vorbereitung der spezifizierten Transaktion für den Koordinator einschließt, bis keine der noch nicht bestätigten Transaktionen eine durchgeführte Operation beinhaltet, die mit einer später durchgeführten Operation in der spezifizierten Transaktion in Konflikt steht, da inzwischen die noch nicht bestätigten Transaktionen bestätigt werden konnten, um so ihren Abbruch zu vermeiden.

9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, daß das Verzögern beendet wird, wenn das Verzögern für eine vorgegebene Zeit andauert.

10. Verfahren nach Anspruch 8, dadurch gekennzeichnet, daß das Verzögern beendet wird, wenn ein Ende-Signal von dem Koordinator empfangen wird.

11. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Prüfung auf Speicherzugriffskonflikte zwischen Transaktionen während der Vorbereitung von Ergebnissen für Transaktionen mit in Konflikt stehenden Operationen durchgeführt wird.

12. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Daten in dem Speicher in der Form eines gerichteten Graphen abgespeichert werden und daß das Verfahren weiterhin den Schritt des Entfernens von Daten bezüglich ausgeführter und abgebrochener Transaktionen von dem Graphen umfaßt.

13. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß von einem Koordinator eine Anforderung empfangen wird, eine spezifizierte Transaktion der Transaktionen vorzubereiten, und daß die Bestätigung der Beendigung der Vorbereitung der spezifizierten Transaktion der Transaktionen verzögert wird, bis keine der Transaktionen, die bis jetzt weder ausgeführt noch abgebrochen wurden, widersprüchlich zu der vordefinierten Ausführungsordnung sind, und daß die spezifizierte Transaktion ausgeführt wird.

14. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Verfahren ferner umfaßt:

• a) Empfangen von Anforderungen, um Transaktionen durchzuführen;
• b) Planen der Durchführung von Operationen der Transaktionen auf einer Echtzeitbasis, so daß Operationen einiger Transaktionen in Übereinstimmung mit der Verfügbarkeit von Systemressourcen des Computers vor der Ausführung anderer Transaktionen durchgeführt werden.

15. Digitales Computersystem zur Verarbeitung von Transaktionen, dadurch gekennzeichnet, daß das System aufweist:

• 1. eine Einrichtung zum Vorbereiten von Ergebnissen der Transaktionen durch Durchführen von Operationen der Transaktionen;
• 2. eine Einrichtung zum Bestätigen von Transaktionen durch Einschreiben der Ergebnisse der Operationen der Transaktionen in einen Zustandsspeicher, wobei das Computersystem ferner aufweist:
• 3. eine Einrichtung zur Prüfung, ob Speicherzugriffskonflikte zwischen den Transaktionen bestehen, wobei nicht alle Transaktionen Speicherzugriffskonflikte aufweisen, und eine Einrichtung zum Aufzeichnen einer Reihenfolge der Durchführung der ersten und zweiten in Konflikt stehenden Operation in einem Speicher des Computersystems, wenn eine der Transaktionen eine erste Operation aufweist, die mit einer zweiten Operation bei einer anderen Transaktion in Konflikt steht;
• 4. eine Einrichtung zum, nachdem die Ergebnisse der Transaktionen mit der ersten bzw. zweiten in Konflikt stehenden Operation vorbereitet wurden, so daß jede der Transaktionen mit der ersten bzw. zweiten in Konflikt stehenden Operation zur Bestätigung vorbereitet ist, Auswählen einer der beiden zu bestätigenden Transaktionen, wodurch eine ausgewählte Transaktion identifiziert wird, und zum Bestimmen eines Abbruchsatzes von Transaktionen, bei denen eine Bestätigung nach der Bestätigung der ausgewählten Transaktion im Widerspruch zu der im Speicher des Computersystems gespeicherten Durchführungsordnung, stehen würde, so daß dieser Satz von Abbruchtransaktionen alle noch nicht bestätigten oder abgebrochenen Transaktionen einschließt, bei denen eine Operation durchgeführt wurde, die mit einer später durchgeführten Operation der ausgewählten Transaktion in Konflikt steht, und die in Abhängigkeit von der Auswahl der ausgewählten Transaktion folgendes ausführt:
• 5. Eingeben der Ergebnisse der ausgewählten Transaktion in einen Zustandsspeicher; und
• 6. Abbrechen aller Transaktionen im Abbruchsatz, wobei der Abbruchsatz zumindest eine Transaktion mit vorbereiteten Ergebnissen umfaßt, die vorbereitet zur Ausführung ist, und eine Operation aufweist, die mit einer später durchgeführten Operation der ausgewählten Transaktion in Konflikt steht.

16. Digitales Computersystem nach Anspruch 15, dadurch gekennzeichnet, daß es ferner umfaßt:
eine Einrichtung zum Empfang einer Anforderung von einem Koordinator zur Spezifizierung einer vorzubereitenden Transaktion, wodurch eine spezifizierte Transaktion identifiziert wird, wobei die Vorbereitung von Ergebnissen für die spezifische Transaktion durch die Einrichtung aus a1) vorgenommen wird,
eine Einrichtung zum Verzögern der Bestätigung der Beendigung der Vorbereitung der spezifischen Transaktion für den Koordinator, bis keine der noch nicht bestätigten oder abgebrochenen Transaktionen eine durchgeführte Operation beinhaltet, die mit einer später durchgeführten Operation der spezifischen Transaktion in Konflikt steht, da inzwischen die noch nicht bestätigten Transaktionen bestätigt werden konnten, um so ihren Abbruch zu vermeiden.

17. System nach einem der Ansprüche 15 oder 16, gekennzeichnet durch eine Einrichtung zum Abbrechen der ausgewählten Transaktionen, nachdem die Verzögerung eine vorgegebene Zeitdauer anhält.

18. System nach einem der Ansprüche 15 bis 17, gekennzeichnet durch eine Einrichtung zum Verzögern der Bestätigung der Beendigung der Vorbereitung der ausgewählten Transaktionen, bis keine der Transaktionen, die noch nicht bestätigt oder abgebrochen worden sind, im Gegensatz zur vorgegebenen Ausführungsreihenfolge und der Ausführung der angeforderten Transaktion stehen.

19. System nach einem der Ansprüche 15 bis 18, gekennzeichnet durch eine Einrichtung zum Vergleichen einer Adresse einer Speicherzugriffsoperation für eine Transaktion mit den Adressen von Speicherzugriffsoperationen, die vorher für eine andere Transaktion durchgeführt worden sind.