DE4216871A1

DE4216871A1 - Ausfuehrungsordnen zum sicherstellen der serienherstellbarkeit verteilter transaktionen

Info

Publication number: DE4216871A1
Application number: DE4216871A
Authority: DE
Inventors: Yoav Raz
Original assignee: Digital Equipment Corp
Current assignee: Digital Equipment Corp
Priority date: 1991-05-21
Filing date: 1992-05-21
Publication date: 1993-01-21
Anticipated expiration: 2012-05-22
Also published as: GB2256514A; JPH05197604A; DE4216871C2; GB9210876D0; US5504900A; GB2256514B

Description

Die vorliegende Erfindung betrifft ganz allgemein eine ver teile Datenverarbeitung, und insbesondere ein Transaktions verarbeitungssystem bzw. ein Dialogverarbeitungssystem, in dem Komponentenoperationen in zugehörigen Transaktionen so verteilt werden, daß zumindest eine Operation bzw. ein Arbeitsablauf oder ein Befehl in einer zweiten Transaktion durchgeführt wird, bevor eine erste Transaktion mit einer in Konflikt stehenden Operation ausgeführt wird. Die vorlie gende Erfindung betrifft insbesondere ein Verfahren und eine Vorrichtung zur (Ablauf-) Planung 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 wahr scheinlich, daß der Speichereintrag fehlerhaft wird. Um das Wiedererlangen bzw. Wiederauffinden von Speichereinträ gen nach einem teilweisen Systemausfall zu ermöglichen, ist es für ein Anwendungsprogramm notwendig, Sicherungsko pien (backup copies) der Einträge in einem nicht flüchtigen Speicher abzuspeichern und zu halten. Wenn das Datenverar beitungssystem wieder gestartet wird, werden die Speicher einträge, die wiedergeholt werden sollen, durch die Sicher heitskopien ersetzt.

Um das Erstellen von Sicherheitskopien und das Heilen von Speichereinträgen bzw. das Wiedererlangen (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 Wiederher stellungseinheit (recovery unit) besteht aus Programmanwei sungen (program statements) zwischen einer "Start"-Anwei sung und einer "Ausführ"-Anweisung (commit statement). Alle Anweisungen in der "Wiederherstellungseinheit" müssen abge schlossen sein, bevor die Speichereinträge, die durch die Anweisungen in der Wiederherstellungseinheit modifiziert werden, für eine nachfolgende Verarbeitung verfügbar ge macht werden. Die "Start"-Anweisung entspricht der Erstel lung einer Sicherungskopie in einem nicht flüchtigen Spei cher und die "Ausführ"-Anweisung entspricht dem Schalten der Sicherungskopie mit einer modifizierten Version bzw. dem Ersetzen der Sicherungskopie durch eine modifizierte Version. Die Anweisungen in der "Wiederherstellungseinheit" spezifizieren Operationen in einer einzelnen "Transaktion". Beim Zurückkehren von einem teilweisen Systemfehler wird die Überprüfung des nicht flüchtigen Speichers (nonvolati le memory) aufdecken bzw. 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 unter schiedlichen Datenbanken modifizieren und auf die Dateien können andere Prozesse zugreifen. Während des Betriebs der Transaktion können die Dateien inkonsistent bzw. unstimmig oder auch widersprüchlich für eine Zeit 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 inkon sistent, da die Summe der beiden Konten nicht die Gesamtgel der 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 Aus führen einer Überweisung für beide Dateien zum gleichen Zeitpunkt und gleichen Ort sichergestellt werden. Durch z. B. das Ändern eines einzelnen Zeichens (flag) können die Sicherungskopien jeder Datei durch die modifizierten Versio nen der Dateien zum gleichen Zeitpunkt ersetzt werden. Bei vielen Anwendungen ist es jedoch wünschenswert, die Opera tionen bzw. Befehle bzw. Arbeitsabläufe 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 Pro zessor auszuführen, wobei eine gewisse Variabilität zwi schen den Ausführungszeitpunkten zugelassen wird. Bei die sen Anwendungen wird ein "Kernausführungsprotokoll" (atomic commitment protocol) typischerweise dazu verwendet, die Wiederherstellbarkeit sicherzustellen. Das Protokoll erfor dert 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. ein zigartige "Transaktionsidentifikationsnummer" (transaction identification number) zugewiesen.

Ein weit verbreitet verwendetes Kernausfü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, zugewie sen. Um eine Transaktion zu beginnen, sendet der Koordina tor einen Vorbereitungsbefehl (prepare command) an alle Prozessoren oder Prozesse, die an der Transaktion teilneh men.

Mit dem Empfang des "Vorbereitungsbefehls" führt jeder Pro zessor 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 Transak tion zugegriffen wird, plaziert, die Transaktionsidentifika tionsnummer 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 bzw. Anerkennung zurück zu dem Koordinationsprozessor sen det, aber noch nicht seinen Teil der Transaktion durch fü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, wo nach der Koordinator "Ausführ"-Befehle an alle Teilnehmer sendet bzw. ausgibt. Der Koordinator kann jedoch eine Nach richt 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 em pfängt, möglicherweise nachdem der Koordinator das "Vorbe reitungs"-Kommando erneut abgesendet hat. In diesem Fall gibt der Koordinator ein "Abbruch"-Kommando (abort command) an alle Teilnehmer aus.

Mit dem Empfang des "Ausführung"-Befehls überprüft jeder Teilnehmer seinen Dauerspeicher nach der Transaktionsidenti fikationsnummer, um zu bestimmen, ob er sich auf die Trans aktion 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) bzw. Einga beoperation oder Übertragungsoperation durch, um den Zu stand bzw. Status des Dauerspeichers zu aktualisieren und die Transaktionsidentifikationsnummer (transaction ID) aus dem Dauerspeicher in einen "Kern"-Schritt ("atomic" step) zu löschen (clear) und löscht (erase) schließlich die Schreibsperren (write locks). Dann sendet der Teilnehmer eine Bestätigung zurück an den Koordinator. Wenn der Koordi nator die Bestätigung 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 Trans aktionen durch. Z. B. können in einem verteilten Datenbanksy stem 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 be schrieben wurde, kann in einem solchen System zufriedenstel lenderweise durchgeführt werden, solange den globalen Trans aktionen eine hohe Priorität gegenüber den lokalen Transak tionen eingeräumt werden kann. Aber den Einsatz von Schreib- und Lesesperren kann unnötigerweise lokale Transak tionen einschränken, die gleichzeitig verarbeitet werden könnten.

Eine zusätzliche Schwierigkeit und Komplexität werden einge führt, wenn es erwünscht ist, globale Transaktionen gleich zeitig in mehreren Prozessoren oder Prozessen eines verteil ten Datenverarbeitungssystems bzw. Verarbeitungssystems auszuführen. Es ist nicht praktisch, 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 Serieneinord nungen der anderen Prozessoren oder Prozesse gibt. Das Zeit markieren (time stamping) von Transaktionsnachfragen (trans action requests) und von Datenaktualisierungen (data up dates) ist ein Verfahren, das verwendet worden ist, um die sem Problem der Gleichzeitigkeitssteuerung und -kontrol le zu begegnen. Im allgemeinen ist eine Gleichzeitigkeits steuerung 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 globa len 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 entschei det, ob gleichzeitige globale Transaktionsnachfragen (glo bal transaction request) gesendet werden oder nicht. Ein Beispiel dafür wird in Y. Breitbart usw., "Reliable Transac tion 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 Transaktionsnach fragen 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 Daten feld zu lesen braucht, fragt nach einer globalen Lesesper re. Sperren stehen in Konflikt zueinander, wenn sie von zwei unterschiedlichen Transaktionen bezüglich des gleichen Datenfelds nachgefragt werden und zumindest eine der nachge fragten Sperren eine Schreibsperre ist. Wenn zwei globale Transaktionen in Konflikt stehende bzw. unverträgliche bzw. unzulässige bzw. widersprüchliche (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 verwen det 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 Wartegra phen" enthalten. Die Transaktion wird nur dann wieder ak tiv, nachdem sie globale Sperren erhalten kann, auf die sie gewartet hat. Um einen globalen Stillstand oder eine globa le Blockierung zu verhindern, wird der "globale Wartegraph" immer azyklisch erstellt. Um eine Datenkonsistenz beim Vor kommen von Ausfällen und Fehlern sicherzustellen, verwen det der Planer ebenfalls einen "Ausführungsgraphen" (commit graph) und einen "Warte-auf-Ausführungsgraphen" (wait-for- commit-graph), um zu bestimmen, wann eine Ausführungsopera tion 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 Trans aktionen, 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üh rungsgraphen.

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üh rungsoperation 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 erfolgrei che Ausführung von nur einer dieser Transaktionen aus, um die Ausführung der Transaktion zu planen!).

Aufgabe der vorliegenden Erfindung ist es, die Serienverar beitung unter verteilten Transaktionen in einem Verarbei tungssystem sicherzustellen.

Diese Aufgabe wird durch das Verfahren nach Anspruch 1 bzw. durch das digitale Computersystem zum Verarbeiten von Trans aktionen nach Anspruch 16 gelöst.

Die vorliegende Erfindung garantiert eine serielle Verarbei tung bzw. Serienherstellbarkeit (serializability) unter verteilten Transaktionen in einem Datenverarbeitungssystem, indem die Transaktionen selektiv ausgeführt und abgebrochen werden, um eine Reihenfolge der Ausführung (oder of commit ment) zu ermöglichen bzw. zu unterstützen, die die gleiche ist, wie eine Reihenfolge der Durchführung von in Konflikt stehenden Komponentenoperationen der Transaktionen. Wenn die Transaktion ausgeführt wird, werden Ergebnisse der Kom ponentenoperationen einem Zustandsspeicher eingegeben. Wenn die Operation abgebrochen wird, werden die Ergebnissse der Komponentenoperationen gelöscht. Z. B. steht eine erste Spei cherzugriffsoperation in einer ersten Transaktion mit einer zweiten Speicherzugriffsoperation in einer zweiten Transak tion in Konflikt, wenn die zwei Speicherzugriffsoperationen die gleiche Speicherstelle betreffen und zumindest eine der Operationen eine Schreiboperation ist.

Bei einem typischen bekannten Transaktionsverarbeitungssy stem kann eine zweite Transaktion nur Daten lesen, die von einer ersten Transaktion geschrieben worden sind, nachdem die zweite Transaktion ausgeführt worden ist. Diese Ein schränkung ist eine ausreichende Bedingung dafür, eine Wie derherstellung des Systems sicherzustellen. Um die vorlie gende Erfindung in diesem Fall praktisch umzusetzen, wenn eine zweite Transaktion eine Leseoperation durchführt, be vor 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 zweite 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 wer den bzw. durchgeführt werden müssen.

Die vorliegende Erfindung erlaubt jedoch die Auslegung ei nes Transaktionsverarbeitungssystems, in dem eine zweite Transaktion Daten lesen kann, die von einer Schreibopera tion einer ersten Transaktion geschrieben worden sind, be vor 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 auftre ten, kann eine der beiden Transaktionen abgebrochen werden, um sicherzustellen, daß die Reihenfolge der Ausführung der Transaktionen die gleiche ist wie die Reihenfolge der Durch führung der in Konflikt stehenden Operationen. Des weite ren, und zwar um eine Wiederherstellbarkeit zu gewährlei sten, 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 zwei te Transaktion Daten lesen kann, die von einer Schreibopera tion einer ersten Transaktion geschrieben worden sind, die Wiederherstellbarkeit durch einen Prozeß kaskadierender Abbrüche (cascading aborts) unterstützt. Das Abbrechen ei ner Transaktion erfordert das zusätzliche Abbrechen aller anderen Transaktionen, die Daten gelesen haben, welche von abgebrochenen Transaktionen geschrieben worden ist.

In Fällen, wo Speicheradressen oder Speicherzugriffsopera tionen 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 Speicher adressen während des Vorbereitens der Transaktionen be stimmt werden.

Die Ausführungsreihenfolge (commitment order) wird durch Ausführen (commiting) einer ausgewählten Transaktion durchge führt bzw. erzwungen, für die ein Ergebnis erzeugt worden ist, und indem andere Transaktionen abgebrochen werden, für die ein Ergebnis gerade erzeugt bzw. vorbereitet wird und für die die Ausführung im Gegensatz zu der vorher definier ten Ausführungsreihenfolge und der Ausführung der ausgewähl ten 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 Li ste durchgeführt wird, indem eine Ausführungsnachfrage von einem Koordinator gemacht wird oder indem eine Strategie verwendet wird, um die Anzahl anderer Transaktionen zu mini mieren, die als Ergebnis der Auswahl abgebrochen werden. In einem Vielprozessorsystem, in dem ein globaler Koordinator mit einer Vielzahl von Transaktionsprozessoren mittels "Vor bereitungs" (prepare)- und "Ausführungs"-Befehlen kommuni ziert, wird die Minimierungsstrategie bevorzugterweise dazu verwendet, um die Bestätigung bzw. Anerkennung zu verzö gern, daß eine Transaktion "vorbereitet" worden ist, bis der "Abbruchsatz" (abort set) der Transaktion minimiert worden ist.

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

Weitere Vorteile und Anwendungsmöglichkeiten der vorliegen den Erfindung werden aus der nachfolgenden Beschreibung bevorzugter Ausführungsformen in Verbindung mit den beilie genden Zeichnungen deutlich. Es zeigt

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 Digi talcomputers der Fig. 1 für Transaktionsverarbeitung, indem die Kopien von nur denjenigen Dateneinträgen des Zustands speichers 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 verschiedene 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 Transaktionsverarbeitungssy stem zwischen einem Transaktionsmanager und einem Systemele mentmanager verwendet wird; und

Fig. 18 ein Zustandsdiagramm eines Transaktionsverarbei tungssystems der Fig. 17

In Fig. 1 wird ein Blockdiagramm gezeigt, das einen digita len Computer 20 zeigt, der für eine Transaktionsverarbei tung ausgelegt ist. Der Computer 20 enthält eine zentrale Verarbeitungseinheit 21 zum Ausführen programmierter Befeh le; einen flüchtigen Speicher mit wahlfreiem Zugriff 22 (random access memory) zum Halten und Speichern von Instruk tionen oder Daten; einen nichtflüchtigen Speicher 23 wie z. B. ein Festplattenlaufwerk, eine Eingangs/Ausgangs-Ein heit 24 und eine Echtzeituhr 25. Der nichtflüchtige Spei cher 23 enthält einen Programmspeicher 26, in dem Programme gespeichert sind und einen Zwischenspeicherbereich 27 (scratch memory area) zum Speichern von Dateneinträgen (da ta records).

Typischerweise führt der Digitalcomputer 20 Programme aus, die von einem Programmspeicher 26 zu dem flüchtigen Spei cher mit wahlfreiem Zugriff 22 transferiert worden sind. Während der Ausführung eines Programms ist es oft notwen dig, 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 Zwischenspeicherbereich 27 bzw. Kellerspeicher oder Daten puffer wiederholt.

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 Spannungsversorung 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 Dateneingang, 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 Prorammierverfahren entwickelt worden, 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 Ergeb nisse der Transaktion in den Zustandsspeicher geschrieben werden, um anzuzeigen, welche Kopie während eines Ausfalls oder Fehlers möglicherweise verfälscht worden ist. Zum Er stellen einer Sicherungskopie des Zustandsspeichers enthält der nichtflüchtige Speicher 23 z. B. zweii Zustandsspeicher banken 28 und 29. Um einen Hinweis dafür zu erzeugen, wel che 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 aufgenom men 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 Transak tion zuerst in den Zustandsspeicher eingeschrieben bzw. übergeben (d. h. eingegeben bzw. ausgeführt (committed)) wurden.

In Fig. 2A wird ein Flußdiagramm einer Prozedur zum Gewähr leisten dargestellt, daß, wenn nach einem Ausfall weiterge arbeitet 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 Compu tersystem 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 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 Ergbenis 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 gele sen und in den Zwischenspeicherbereich 27 übertragen. Dann werden die Einträge des Zwischenspeichers gemäß den Ergeb nissen 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 ge setzt. Beim Schritt 70 werden dann die Ergebnisse der Trans aktion übertragen (comitted), indem die modifizierten Daten in die Zustandsspeicherbank 28 eingeschrieben werden. Schließlich wird beim Schritt 64 das Kennzeichen im nicht flü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 Se quenz durch die zentrale Verarbeitungseinheit 21 des Compu ters 20 nach Fig. 1 abgearbeitet bzw. verarbeitet werden. Die vorliegende Erfindung erlaubt es jedoch, daß die Verar beitung der Transaktionen so verteilt wird, daß die Ergeb nisse 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 Echtzeitbe triebssystem oder einen Planer umfaßt, um die zentrale Ver arbeitungseinheit während der Zeit effektiver auszunutzen bzw. zu beschäftigen, während der sie ansonsten auf die Beendigung von Eingabe/Ausgabe- oder Speicherzugriffsopera tionen warten würde. Indem es erlaubt wird, daß eine zweite Transaktion Komponentenoperationen durchführt, bevor eine erste Transaktion ihre Ergebnisse übertragen bzw. eingege ben (committed) hat, wird jedoch das Problem der Inkonsi stenz eingeführt, bis das Planen der Operationen und die Ausführung bzw. Übertragung der Transaktionen mit einer bestimmten Durchführungsreihenfolge übereinstimmt. Insbeson dere sollten die Transaktionen in der gleichen Reihenfolge ausgeführt werden, wie die Reihenfolge, in der die zugehöri gen in Konflikt stehenden (d. h. nicht umgewandelten (non-commuting)) Operationen durchgeführt werden.

Wenn das Planen der Komponentenoperationen und die Ausfüh rung der Transaktionen diese Eigenschaft der "Ausführungs reihenfolge" (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 "Kernübertragung" (atomic comitment) eingesetzt wird, um die verschiedenen Prozessoren des Systems zu koor dinieren. Dies wird durch eine ziemlich aufwendige mathema tische Überprüfung belegt, welche an die vorliegende Be schreibung angehängt ist (vergleiche Anhang I). Von einem praktischen Gesichtspunkt bzw. Standpunkt aus bedeutet die ses Ergebnis, daß die Vorteile der vorliegenden Erfindung auf ein herkömmliches verteiltes Transaktionsverarbeitungs system angewendet werden können, indem jeder Transaktions prozessor oder Knoten des Systems ohne Modifikation des globalen Planers oder des Protokolls für das Verteilen glo baler 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 Trans aktion ausgeführt worden ist. Dies ist eine ausreichende aber nicht notwendige Bedingung dafür, eine Wiederher herstellung 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 ein 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 dem 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 Erzwin gen der Ausführungsreihenfolge verwendet werden. Um die Ergebnisse der Transaktionen in den Zustandsspeicher 28, 29 zu übertragen und von Ausfällen bzw. Fehlern zurückzukeh ren, ist der digitale Computer mit einem Systemelement-Mana ger (RM) 81 versehen, der z. B. die Operationen, die in Fig. 2B gezeigt werden, durchführt. Im allgemeinen ist ein Sy stemelementmanager (RM) eine Softwarekomponente, die die Zustandsspeicher-Systemelemente, welche durch übertragende Transaktionen berührt werden, so betreibt, daß der Speicher zustand 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 Transaktio nen die Eigenschaft der "Kernigkeit" (atomicity) oder von "alles oder nichts"-Semantik bezüglich ihrer Zustandsspei cher-Systemelemente haben. Ein Systemelement ist typischer weise 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 effi zientesten Reihenfolge auf der Basis von verfügbaren Sy stemelementen für den Computer zu planen, ist ein Transak tionsplaner (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 Transaktionen, 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 9 beschrieben wird. Die "nichtentschiedenen Transaktionen" sind die Transaktionen, die noch ausgeführt werden oder abgebrochen werden. Um die Ausführungsreihenfolge festzulegen, werden Transaktionen für die Ausführung ausgewählt und Transaktionen werden selektiv abgebrochen durch einen Ausfü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 Komponentenoperationen der gleichen Transaktion gleichzeitig in unterschiedlichen Prozessoren durchgeführt werden. Ein Vielprozessorsystem 90 wird in Fig. 4B erläutert. In diesem Fall sind drei digitale Computer 91, 92, 93 über einen Kommunikationskanal 94 miteinander verbunden und die Kommunikation wird durch die Transaktionsplaner (TS) 95, 96, 97 gesteuert. In dem Multiprozessorsystem 90 kann jeder der Transaktionsplaner 95, 96, 97 die Rolle eines Koordinators annehmen und globale Transaktionen an die anderen Transaktionsplaner ausgeben. Diese globalen Transaktionen werden z. B. gemäß dem bekannten Zwei-Phasenausführungsprotokoll koordiniert, wie oben mit Bezug auf den Stand der Technik erläutert 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 Objekten 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 Komponentenoperationen 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 Transaktionsplaner für Echtzeitplanen von Komponentenoperationen oder Transaktionen in Übereinstimmung mit erhältlichen Systemelementen des digitalen Computers nachfolgt. Insbesondere enthalten die Transaktionen Eingabe/Ausgabe und Speicherzugriffe auf einen rotierenden Speicher wie z. B. Plattenlaufwerke und möglicherweise mathematische Berechnungen, die von einem Coprocessor durchgeführt werden. Ohne Echtzeitplanen würde die zentrale Verarbeitungseinheit des digitalen 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öglichen, die Ausführung (execution) zu einer anderen Transaktion zu transferieren. Wenn die nachgefragte Eingabe/Ausgabe- oder Speicherzugriffsoperation abgeschlossen ist, gibt die Eingabe/Ausgabe- oder Speichereinrichtung einen Abschluß- Interrupt aus, der von einer Interrupt-Behandlungsroutine verarbeitet wird, die das Sperrzeichen der Transaktion zurücknimmt bzw. löscht, welche die Eingabe/Ausgabe- oder Speicherzugriffsoperation nachgefragt hat. Die Beendigungsinterrupts der Eingabe/Ausgabe- und Speicherzugriffe und Bearbeitungsprogramme (device handlers) für solche Interrupts 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 unterbrochenen Transaktion aus dem Prozessorstapelspeicher des digitalen Computers und durch Unterbringen des Kontextes in einem entsprechenden Textspeicher für die unterbrochene Transaktion reagiert. Der Kontext enthält den Wert des Programmzählers, der auf die unterbrochene Speicherstelle in dem Transaktionsprogramm 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 (star-up) des digitalen Computers beim Schritt 102 betreten werden. Beim Schritt 102 werden die Transaktionsliste 83 und weitere Datenstrukturen, 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 Speicheroperation nachgefragt hat.

Der Transaktionsplaner führt drei Hauptaufgaben (major tasks) durch: er antwortet auf Transaktionsnachfragen durch Plazieren der Transaktionen auf der Transaktionsliste; er löste die Ausführung bereitstehender Transaktionen aus und er plant die Durchführung von Komponentenoperationen der Transaktionen. Beim Schritt 104 überprüft der Transaktionsplaner z. B., ob eine Transaktion nachgefragt hat. Ein Transaktionsplaner- Interrupt kann z. B. in Antwort auf ein Interrupt- Signal von der Eingabe/Ausgabe-Einheit auftreten, der anzeigt, daß ein Benutzer oder ein anderer digitaler Computer 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 Transaktionsliste 83. Die Transaktionsliste enthält eine Verbindungsliste (linked list) von Transaktionsedentifikationsnummern 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. Diese 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 Transaktion 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 Speicherzugriffsnachfrage, ein Zeichen G, das angibt, ob die Transaktion eine lokale oder globale Transaktion ist, und ein Zeichen 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. Übertragung bereit ist. Wenn das der Fall ist, ruft der Transaktionsplaner 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 Koordinator für die Ausführungsreihenfolge beschließt, die Ausführung nicht zu verzögern, dann überträgt der Systemelement- Manager (RM) beim Schritt 115 die Ergebnisse der Transaktion 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. zuerst, 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 Transaktion 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 Transaktionsplaner 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 nichtgesperrte Transaktion, die noch nicht bereit ist, gefunden wird oder das Ende der Liste erreicht worden ist.

Wenn eine nicht gesperrte Transaktion, die noch nicht bereit 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 Anfangskontext 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 Ausführung von Instruktionen bzw. Befehlen in dem Programm für die ausgewählte Transaktion anzufangen oder fortzusetzen.

Fig. 7 zeigt ein spezielles Beispiel einer Datenstruktur zum Speichern des Seriengraphen (USG) für nicht entschiedene Transaktionen. Immer dann, wenn eine bestimmte Reihenfolge für die Durchführung von in Konflikt stehenden Operationen in einem jeweiligen Paar von Transaktionen eingerichtet worden ist, wird die Reihenfolge der Durchführung der in Konflikt befindlichen Operationen in dem Seriengraphen für nicht entschiedene Transaktionen notiert. Wenn die Speicherzugriffsoperationen, die von jeder Transaktion durchgeführt werden, und die Speicherstellen dieser Speicherzugriffsoperationen zu einem 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) durchgeführt werden. Außer in diesem bestimmten Fall wird die Reihenfolge der Durchführung von in Konflikt stehenden Operationen bestimmt, wenn eine zweite der in Konflikt stehenden Operationen für die Durchführung durch den Transaktionsplaner eingeplant wird und die Speicherstelle, auf die durch die in Konflikt stehende Operation zugegriffen wird, bestimmt 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ührung der in Konflikt stehenden Operationen der Transaktionen an. Wenn diese Reihenfolge der Durchführung einmal eingerichtet ist, wird sie durch Abbrechen von Transaktionen oder Verzögern von Transaktionen oder zusätzlichen in Konflikt 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ührung 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 Transaktionen Priorität über lokale Transaktionen in dem Auswahlvorgang haben.

Beim Schritt 142 wird die Ausführungsreihenfolge durch Abbrechen der Transaktionen erzwungen, für die die Ausü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₁ ausgewählt wird, die Transaktionen T₀ und T₃ abgebrochen, um die Ausführungsreihenfolge zu erzwingen. Das Abbrechen einer Transaktion umfaßt das Löschen der Ergebnisse jeder Transaktion. Bei lokalen Transaktionen kann eine Transaktion durch Zurücksetzen der Inhalte ihrer jeweiligen Kontextspeicher auf ihren Anfangskontext abgebrochen werden. Anders ausgedrückt wird der gegenwärtige Wert des Programmzählers für die Transaktion auf den Anfang des Programms für die Transaktion zurückgesetzt. Zudem müssen die Transaktionsliste 106 und der Seriengraph 84 für nicht entschiedene Transaktionen neu initialisiert werden. Bei globalen Transaktionen wird eine abgebrochene Transaktion wenn überhaupt von dem Koordinator neu gestartet. In diesem 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 Transaktion 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 Teilnehmer in dem "Abbruchsatz" (abort set) der ausgewählten Transaktionen gezählt. Mit Bezug auf den Seriengraphen 84 für nicht entschiedene Transaktionen der Fig. 8 enthält z. B. der Abbruchsatz 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 Teilnehmer eines Abbruchsatzes einer Transaktion durch die Kantenzeiten (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 Zeichen, die in der entsprechenden Spalte für die Transaktion gesetzt sind, berechnet. Wenn der Abbruchsatz der ausgewählten 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 Transaktionsverarbeitungssystem beschrieben wird, das lokale und globale 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 angemerkt, daß der Abbruchsatz einer bereitstehenden Transaktion 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 ausgewählten Transaktion wird deshalb beendet bzw. abgeschlossen, 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önnten, 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 Adreßübereinstimmung gibt, wie es beim Schritt 173 getestet wird, wird beim Schritt 180 die gegenwärtige Reihenfolge der Transaktion in dem Seriengraphen für nicht entschiedene Transaktionen (84 in Fig. 7) aufgezeichnet. Insbesondere treten Konflikte für den Fall 1 der Fig. 3A nur zwischen einer Leseoperation und einer Schreiboperation auf und die Reihenfolge der Operationen ist Lesen, dann Schreiben. 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 Adreßliste für Lese- und Schreiboperationen der gegenwärtigen Transaktion fortgesetzt. 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 werden, 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 bestehen, 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 Transaktion 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 Transaktionsverarbeitungssystem so arbeitet, wie es oben mit Bezug auf Fig. 3B beschrieben 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 geschrieben worden sind. Dann wird bei Schritt 192 die Transaktion 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 Transaktionsverarbeitungssystems 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 Transaktionsplaner die Transaktionsnachfrage und setzt die Transaktionsnachfrage 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 Vorbereitung befindlichen Transaktion und die Transaktion wird ausgefü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 Speicheroperation wird die Transaktion freigegeben. Eine Transaktion, die entweder in Vorbereitung, gesperrt oder fertig bzw. abgeschlossen ist, kann abgebrochen werden, um eine Ausführungsreihenfolge zu erzwingen.

Der Transaktionsplaner kann eine fertige lokale Transaktion ausführen. Um eine globale Synchronisation in einem verteilten Transaktionsverarbeitungssystem sicherzustellen, wird jedoch eine fertige globale Transaktion nur nach einer Quittierung (handshake) mit dem Koordinator ausgeführt. Diese Quittierung stellt sicher, daß eine globale Transaktion nicht ausgeführt wird, bis alle Prozessoren, die zugewiesene Abschnitte der Transaktion verarbeiten, ebenfalls fertig sind, oder bereit sind, ihre zugewiesenen Abschnitte der globalen Transaktion auszuführen bzw. zu übertragen. Deshalb, wenn der Transaktionsplaner den Zustand einer globalen 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 allen Transaktionsplanern, die an einer Transaktion teilnehmen, empfangen hat, sendet der Koordinator einen "Ausführungs"- Befehl an den Transaktionsplaner zurück. Wenn der Koordinator jedoch nicht ein "Vorbereitet"-Signal von allen teilnehmenden Transaktionsplanern empfängt, kann der Koordinator ein "Abbruch"-Signal an den Transaktionsplaner senden. In Fig. 14 werden diese Quittierungssignale durch gepunktete 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 Transaktionsplaner 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 Vorbereitung 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 Transaktionen zu löschen (clear) und den Zustand der Transaktion zurück in "Vorbereitung" zu setzen, indem die R- und I-Zeichen 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 globalen 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 signal) von dem Koordinator empfangen haben. Dieses Signal kann ein spezielles Signal vom Koordinator sein oder es kann eine erneute Sendung einer vorher zugesendeten Transaktionsnachfrage sein. Wenn ein solches Signal empfangen wird, wird beim Schritt 212 das R-Zeichen für die Transaktion 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. Ansonsten werden dann die Teilnehmer des Abbruchsatzes für die Transaktion beim Schritt 213 überprüft, um zu bestimmen, 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 ausgewä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 gesetzten P-Zeichen aufweist, kann die ausgewählte Transaktion nicht vor der globalen Transaktion mit dem gesetzten P-Zeichen 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 abgesendet hat und ein bestätigendes "Ausführungs"-Signal (commit signal) empfangen hat. Bei einer globalen Transaktion wird deshalb das Vorbereitungs-Anerkennungs-Signal ("vorbereitet" in Fig. 14) an den Koordinator beim Schritt 216 gesendet, das P-Zeichen für die globale Transaktion in der Transaktionsliste wird gesetzt und die Ausführung im Transaktionsplaner wird fortgesetzt. Ansonsten werden bei einer auszuführenden lokalen Transaktion beim Schritt 215 die Transaktionen in dem Abbruchsatz abgebrochen (und der "kaskadierende 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. Verwalten 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 Abbruch 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 Transaktionen 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 Interrupt 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ählten Transaktion werden in den Zustandsspeicher übertragen. Dann wird beim Schritt 223 eine Anerkennung bzw. Bestätigung 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 Erfindung, 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-Manager (RM=resource manager) 253 aufweist. Wie gezeigt, besteht der Ausführungsreihenfolgenkoordinator 251 aus einem Untersatz der Schnittstelle 254 zwischen dem Transaktionsmanager 252 und dem Systemelement-Manager 253. Der Ausführungsreihenfolgenkoordinator ü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ührungsreihenfolgenkoordinators 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 empfangen wird;
R_AUSFÜHREN(T) (=R_COMMIT): Der TM zeigt dem RM an, die Transaktion T auszuführen. Eine Voraussetzung für das Aufrufen 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öglicherweise auch allen anderen RM's 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 abzubrechen 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 beteiligten RMs resultiert).

Wenn die TM-RM Schnittstelle 254 eingefügt ist, ruft der Ausführungsreihenfolgenkoordinator 251, und nicht der Systemelementmanager 253, direkt die T_FERTIG(T) und T_ABBRUCH(T) Dienste des Transaktionsmanagers 252 auf. Des weiteren 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 Identifizierung der Dienste in der nachfolgenden Beschreibung, werden die Dienste des Ausführungsreihenfolgenkoordinators bezüglich dieser Signale als C_T_AUSFÜHRUNG(T) bzw. C_T_ABBRUCH(T) bezeichnet.

Das RM-COCO-Interface ist ein Untersatz der TM-COCO-Schnittstelle. Insbesondere werden zusätzliche Dienste zum Aufrechterhalten des USG, der Datenstruktur des COCO, definiert. Die Signale des RM, die vorher die herkömmlichen T_FERTIG(T) und T_ABBRUCH(T) Dienste des Transaktionsmanagers aufgerufen haben, rufen jetzt die Dienste C_R_FERTIG(T) und C_R_ABBRUCH(T) des Ausführungsreihenfolgenkoordinators 251 auf. Der Ausführungsreihenfolgenkoordinator 251 wird auch durch den Systemelementmanager 253 aufgerufen, um die nachfolgenden zusätzlichen Dienste des Ausführungsreihenfolgenkoordinators durchzuführen:
C_R_ANFANG(T) (=C_R_BEGINN): Der RM zeigt dem COCO an, einen 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 diesen Dienst auf, um dies dem COCO anzuzeigen. Wenn eine zugeordnete 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 Anerkennungssignals von dem COCO ausgeführt, um sicherzustellen, daß der USG zu diesem Zeitpunkt aktualisiert ist. Der Systemelementmanager 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ügu 50136 00070 552 001000280000000200012000285915002500040 0002004216871 00004 50017ng 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₁, T2) 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 Komponentenoperationen einer Anzahl von Transaktionen für die Ausführung in einer Art und Weise verteilt und eingeplant werden, die für den Einsatz erhältlicher Rechnerverarbeitungskapazitäten am effizientesten ist. Außerdem kann die Konsistenz durch Erzwingen einer Ausführungsreihenfolge aufrechterhalten werden, in der Transaktionen in der gleichen Reihenfolge ausgeführt werden, mit der auch in Konflikt stehende Operationen durchgeführt werden. In einem verteilten Transaktionsverarbeitungssystem stellt die Übereinstimmung mit einer Ausführungsreihenfolge die serielle Abarbeitung eines kombinierten (globalen) Planes sicher. Des weiteren wird die serielle Abarbeitung des kombinierten (globalen) 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 Komponentenoperationen der Transaktionen. Eine erste Speicherzugriffsoperation 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 Transaktionsverarbeitungssystem kann einer zweiten Transaktion gestatten, Daten zu lesen, die von einer Schreiboperation einer ersten Transaktion geschrieben wurden, bevor die erste Transaktion ausgeführt wird. In diesem Fall wird, in Abhängigkeit von der jeweiligen Reihenfolge, in der die zwei in Konflikt stehenden Operationen auftreten, die Ausführungsreihenfolge erzwungen, möglicherweise durch Abbrechen einer der zwei Transaktionen, um sicherzustellen, daß die Ausführungsreihenfolge die gleiche ist wie die Reihenfolge der Operationen. Die Konflikte werden z. B. detektiert, wenn die Adressen während einer Vorbereitungsphase der Transaktion bestimmt werden. Die Komponentenoperationen können z. B. gemäß des am meisten effizienten Einsatzes der Computersystemkapazitäten geplant werden. In einem Multiprozessorsystem, in dem ein globaler Koordinator mit einer Vielzahl von Transaktionsprozessen mittels "Vorbereitungs"- und "Ausführungs"- Kommandos kommuniziert, wird in der Ausführungsreihenfolge auf Verzögerungsbestätigungen Bezug genommen, daß eine Transaktion "vorbereitet" worden ist, bis der "Abbruchssatz" der Transaktion minimiert worden ist.

Anhang I Definitionen und Nachweise für Eigenschaften des Ausführungsordnens

Nachfolgend wird gezeigt, daß eine zeitliche Eigenschaft (history property), die als "Ausführungsreihenfolge" bezeichnet wird, das globale Problem der seriellen Abarbeitung löst. Insbesondere wird eine globale serielle Abarbeitung garantiert, wenn jeder Systemelementmanager in einem verteilten Transaktionsverarbeitungssystem der "Ausführungsreihenfolge" (commitment ordering) folgt und wenn sie Systemelementmanager "autonom" sind (d. h., sie koordinieren über Kernausführungsprotokolle (atomic commitment protocols) und tauschen keine zusätzliche gleichzeitige Steuerinformation 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 Transaktion aus dem Kontext bekannt ist. Die Ereignisse umfassen Lese- und Schreiboperationen; r_i[x] bezeichnet, daß die Transaktion T_i das Datenfeld x gelesen hat, und w_i[x] bedeutet, 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

2. 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.

3. 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

4. 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.

5. 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

6. Wenn T_i in T ist und Ereignis_a<_iEreignis_b, dann ist Ereignis_a<_HEreignis_b.

7. 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]<_Hp_i[x].

8. 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_i. (Dieses Axiom liefert 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). (Bemerke: Der Index H in <_H kann weggelassen werden, wenn H aus dem Kontext bekannt ist.)

Definitionen

9. Eine History (Ablauf, Reihenfolge) ist jedes Präfix einer kompletten History. Ein Präfix einer partiellen Ordnung P über einem Satz S ist eine partielle Reihe P′ über einem Satz S′⊆S mit den folgenden Eigenschaften:

Wenn b∈S′ und a<_pb, dann auch a∈S′
Wenn a,b∈S′, dann a<_pb, wenn und nur wenn a<_p′ b

10. Eine Transaktion T₂ ist in Konflikt mit einer Transaktion T₁, wenn und nur wenn für die zugehörigen in Konflikt stehenden Operationen q₂[x], p₁[x] gilt, daß p₁[x]<q₂[x] (Merke, daß diese Definition asymmetrisch ist).

11. 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₁.

12. 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₁.

13. Wenn p₁ ist r₁[x] und q₂[x] ist w₂[x], dann ist T₂ in einem rw-Konflikt (Lese/Schreib-Konflikt) mit der Transaktion T₁.

14. Es gibt eine Konfliktäquivalenz zwischen zwei Historien H und H′ (die zwei sind konfliktäquivalent), wenn und nur wenn beide im gleichen Satz von Transaktionen T definiert sind und aus den gleichen Transaktionsereignissen (für teilweise ausgeführte Transaktionen) bestehen und p_i[x]<_h q_j[x] ist, 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 ausgeführten Transaktion T_i bzw. T_j in T gilt (d. h., H und H′ haben die gleichen Konflikte zwischen Operationen der ausgeführten Transaktionen.

15. Eine History H bezüglich eines Transaktionssatzes T ist seriell, wenn und nur wenn für jeweils zwei Transaktionen 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).

16. Eine History ist einreihbar, seriell anordenbar (SER; ist in SER), wenn und nur wenn sie konfliktäquivalent zu einer irgendwie seriellen History ist.

17. Seriengraph einer History H, SG(H) ist der gerichtete Graph SG(H)=(T,C), wobei T der Satz aller nicht abgebrochenen (d. h. ausgeführten und unvollständigen) Transaktionen in H ist und C (ein Untersatz von TxT) 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) Transaktionen als Knoten und mit all den zugehörigen Kanten.

Das Reihenanordnungs-Theorem (Serializability theorem)

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

Definitionen

19. Eine History H ist behebbar (recoverable) (REC; ist REC), wenn und nur wenn für irgendwelche zwei Transaktionen T₁, T₂ ist H immer gilt, wenn T₂ ist in einem wr-Konflikt mit T₁, daß T₂ nur ausgeführt wird, nachdem T₁ ausgefü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)).

20. Die History H vermeidet kaskadierende Abbrüche (cascading aborts) (ACA; ist in ACA), wenn und nur wenn irgendeine 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].

21. Man nehme an T₁, T₂ sind irgendwelche zwei Transaktionen 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

22. REC⊃ACA⊃ST wobei ⊃ eine strikt einzuhaltende Bedingung (containment) bezeichnet (Dieses Theorem folgt unmittelbar aus den Definitionen).

Definitionen

23. 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).

24. Eine History ist in einem streng-strikten Zwei-Phasen-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₁ und 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-Phasen-Sperrmechanismus erzeugt werden kann. Eine strikte Zwei-Phasen-Sperrung erfordert, daß Schreibsperren, die im 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-Phasen-Sperrmechanismus. Die streng-strikte Zwei-Phasen-Sperrung erfordert, daß alle Sperren nicht gelöst werden, bevor die Transaktion abgeschlossen ist (wenn sie entweder ausgeführt oder abgebrochen ist.) Eine streng-strikte Zwei-Phasen-Sperrung blockiert irgendwelche in Konflikt stehende Operation bezüglich eines Datenfelds, auf das von einer Transaktion zugegriffen wird, bis zum Ende der Transaktion.)

25. Ein Mechanismus blockiert, wenn er in einigen Situationen Ereignisse in einer Transaktion verzögert, bis gewisse Ereignisse in anderen Transaktionen auftreten.

26. Eine History-Eigenschaft ist inhärent blockierend, wenn sie nur durch einen Blockiermechanismus erzwungen werden kann.

27. Eine History-Eigenschaft ist nicht inhärent blockierend (non inherently blocking), wenn sie durch irgendeinen nicht blockierenden Mechanismus erzwungen werden kann. (Bemerkung: Sowohl die Serienherstellbarkeit als auch die Wiederherstellbarkeit sind nicht inhärent blockierend, da sie immer sichergestellt werden können, indem eine verletzende Transaktion zu irgendeinem Zeitpunkt vor ihrem Ende abgebrochen wird. Diese Beobachtung ist die Basis für eine optimistische Gleichzeitigkeitssteuerung (optimistic concurrency control), bei der Transaktionen ohne ein gegenseitiges 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.)

28. Eine Transaktion wird entschieden (decided), wenn und nur wenn sie entweder abgebrochen oder ausgeführt wird; ansonsten ist sie nicht entschieden (undecided).

29. Eine nicht entschiedene Transaktion ist fertig (ready), wenn und nur wenn sie ihre Verarbeitung abgeschlossen hat und vorbereitet ist, entweder ausgeführt bzw. übertragen oder abgebrochen zu werden; ansonsten ist sie aktiv.

30. Eine Transaktion ist nicht entschieden, wenn und nur wenn sie entweder fertig oder aktiv ist.

Ausführungsreihenfolge Definition

31. Eine History hat die Ausführungsreihenfolgeneigenschaft (Comitment Ordering (CO) property) (d. h., sie ist in CO), wenn und nur wenn für irgendwelche in Konflikt stehende Operationen p₁[x], q₂[x] von ausgeführten Transaktionen T₁ bzw. T₂ p₁[x]<q₂[x] bedeutet e₁<e₂. Formelmäßig ausgedrückt (e₁=c und e₂=c und p₁[x]<q₂[x]) bedeutet e₁<e₂.

Ausführungsreihenfolgentheorem (Commitment Ordering Theorem)

32. 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 R 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 (1.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 Beziehung "<" asymmetrisch ist. Deshalb ist CSG (H) azyklisch und H ist in SER bdurch 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

33. Ein Gleichzeitigkeitssteuermechanismus für Zeitmarkierungsordnen (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; Zeitmarkierungen sind unterschiedlich.

Regel für Zeitmarkierungs-Reihenfolge

34. 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 Gleichzeitigkeitssteuerung auf Basis des Zeitmarkierungsordnens (optimistic timestamp ordering based concurrency control) dar, aber auch die Basis für blockierende zeitmarkierungsordnende Mechanismen.

Regel für blockierende Zeitmarkierungsordnung

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

Regel für zeitmarkierendes Ausführungsordnen

36. Für beliebige zwei ausgeführte Transaktionen T₁ bzw. T₂ mit zugehörigen in Konflikt stehenden Operationen bedeutet 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

37. Eine History hat die Ausführungsreihenfolge-Eigenschaft, wenn und nur wenn sie durch einen Mechanismus erzeugt wird, der sowohl der Regel für Zeitmarkierungsordnen (34) als auch der Regel für Zeitmarkierungsausführungsordnen (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ührungsordnungseigenschaft erzeugt werden. Die TCO-Regel kann einfach durch Verzögern von Ausführungsereignissen erzwungen werden, wenn es notwendig ist, der Zeitmarkierungsordnung nachzukommen.)

Definitionen

38. Transaktionsende-Planer (TTS) (=transaction termination scheduler) ist ein Systemelement, das den Satz fertiger Transaktionen überwacht und entscheidet, wann und welche Transaktion ausgeführt bzw. abgebrochen wird. In einer Managerumgebung für viele Systemelemente nimmt dieses Systemelement 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ührung für jede relevante Transaktion erhalten wurde.

39. 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 Serienherstellbarkeitsgraphen bzw. Seriengraphen USC aller nicht entschiedenen Transaktionen aufrecht. Jede neue Transaktion, die von dem RM verarbeitet wird, wird als neuer Knoten im USG wiedergegeben; jeder Konflikt zwischen Transaktionen im USG wird durch eine gerichtete Kante wiedergegeben (eine Kante zwischen zwei Transaktionen kann somit mehrere Konflikte wiedergeben). USG (H)=(UT,C), wobei UT der Satz aller unentschiedenen 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

40. Der COTTS erzeugt Historyn mit der Ausführungsreihenfolgeneigenschaft (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_n durchgeführt (ohne Verlust an Allgemeingültigkeit). H_n+1 enthält alle Transaktionen in H_n und die neuen (nicht entschiedenen) 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 Iteration n+1:

(a) Man lasse T₂, T₃ (ohne Verlust an Allgemeingültigkeit) 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 die Transaktion existiert, die nicht in einem Zyklus des USG vorkommt, dann existiert eine Transaktion T mit keinen Kanten von irgendeiner anderen Transaktion. T kann ohne Abbrechen irgendeiner anderen Transaktion ausgeführt werden, da ABORT_co(T) leer ist. Wenn alle Transaktionen in USG auf Zyklen sind, muß zumindest eine Transaktion abgebrochen werden. Diese Situation scheint ungewö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ührungsprotokoll (=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 verzö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 resultieren 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

41. 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-Kante 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 abgebrochen wurden (um zukünftige Verletzungen der Ausführungsordnung zu verhindern), wie 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 abgebrochenen Transaktionen auf Grund der Wiederherstellbarkeit als Ergebnis einer abgebrochenen Transaktion T′ wird wie folgt definiert:

ABORT_BEC(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 irgendeine Transaktion T′ in ABORT_co(T) ist; damit die Notwendigkeit 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 ABORTco(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 Transaktionen (T und alle abgebrochenen Transaktionen) aus dem Graphen. (Bemerkung: Während jeder Iteration soll wr-USG alle Operationskonflikte bis zur Ausführung wiedergeben.)

Theorem

42. 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 Wiederherstellbarkeitserfordernisses). 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 abgebrochene 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

43. Ein COTTS erzeugt Historien, die serienherstellbar sind.

44. Ein CORTTS erzeugt Historien, die sowohl serienherstellbar als auch behebbar sind.

45. Nicht-blockierende Planer auf der Basis von COTTS und CORTTS erzeugen stillstandsfreie Ausführungen. (Bemerke: Die TTS können mit irgendwelchen Systemelementzugriffsplanern (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 Kombination aus einem RAS und einem TTS kann den obenstehenden RAS ersetzen, wenn eine gewisse Filterung (durch einen TTS) erforderlich ist, um weitere History-Eigenschaften aufzuerlegen. 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 Transaktionen 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 ein extremer Fall. Andere Planertypen können andere Eigenschaften der zugehörigen USGs mit sich bringen, um gewünschte Planungsmuster und Systemeigenschaften bzw. Verhalten zu ermöglichen, und zwar gemäß der Natur der auftretenden Transaktionen. Es ist auch darauf hinzuweisen, daß, wenn der kombinierte 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ührungsordnen mit Zeitmarkierung erzwungen wird.

Definitionen

46. Eine Umgebung (environment) weist ein System mit verteilten Diensten auf, das eine Vielzahl von Systemelementmanagern (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

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

Definitionen

48. Eine globale Transaktion T_j besteht aus einem oder mehreren lokalen Untertransaktionen (subtransactions). Eine lokale Untertransaktion T_i,j greift auf alle Daten unter der Steuerung eines RM j zu, die T_i zum Zugreifen benötigt, und nur auf diese Datenfehler (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 Transaktion.

49. Eine lokale History wird durch einen einzelnen RM erzeugt und über den Satz ihrer lokalen Untertransaktionen definiert. Eine lokale History gehorcht der Definition einer History in Abschnitt 2. H_i ist eine History, die von einem RM i mit einer Beziehung <_Hi erzeugt wurde. (Bemerke: Es wird angenommen, daß ein Kernausführungsprotokoll (AC) (atomic commitment protocol) angewendet wird, um die Kerneigenschaft (atomicity) in der verteilten Umgebung sicherzustellen.)

50. Ein AC-Protokoll implementiert das folgende generelle 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 Untertransaktion 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 Wiederherstellungsausgaben 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:

Die RMs erzeugen die nachfolgenden (lokalen) Historien H₁ und H₂:

RM 1: H₁ r_1,1[x]w_2,1[x]c₂c₁
RM 2: H₂ w_2,2[y]c₂r_1,2[y]c₁

Man bemerke, daß die History H₁ die Ausführungsreihenfolge verletzt, was in einer (globalen) Serienherstellbarkeitsverletzung 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₂

51. Für jede History-Eigenschaft X ist eine (globale) History H in Lokal-X (ist lokales X), wenn und nur wenn für jedes RM i in der Umgebung H_i (die History von RM i) in X ist (ist X).

Theorem

52. 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

53. 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 obenstehenden 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

54. SER⊃Lokal-CO. Anders ausgedrückt, wenn eine History in Lokal-CO ist, dann ist sie global seriell angeordnet. 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

55. Eine dauerhafte Risikotransaktion (permanent risk transaction (PR)) ist eine Transaktion, die eine potentielle Verletzung der Serieneigenschaft verursacht, wenn sie ausgeführt wird, und in dieser Situation für immer bleibt. Die Eigenschaft bezieht sich auf den Systemelementmanager. 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 Transaktion 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. Ansonsten 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

56. Wenn nur eine Information über lokale Serieneigenschaft 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 globale 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 RM i, seinen lokalen Serieneigenschaftsgraphen SG_i "weiß" (er enthält alle ausgeführten und nicht entschiedenen Transaktionen) und seine Untergraphen CSG_i (die nur ausgeführte Transaktionen enthalten) und USG_i (der alle nicht entscheidenen 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 Transaktion teilnehmen, "Ja" gewählt haben, und sie schließlich ausgeführt hat. Das Ziel für jeden RM ist es, einen zyklusfreien (globalen) CSG sicherzustellen (einen Seriengraphen mit ausgeführten Transaktionen), in dem jede Aktion vermieden wird, die einen globalen Zyklus (lokale Zyklen im CSG_i werden durch den RM i 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 Serieneigenschaft verursachen kann, ausgeführt werden. Es ist nun notwendig, permanente Risikotransaktionen (PR) zu identifizieren, 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 Transaktion 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 RM j gibt, wobei j≠i ist, aber RM i kann dies nicht überprüfen. Das bedeutet, daß das spätere Ausführen von T′ einen Zyklus in CSG verursachen 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 Situation ändern. Deshalb ist T′ eine PR und RM i muß sie abbrechen.
(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 Übereinstimmung 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 RM j, wobei j≠i ist, zu haben, da, wenn dieser Pfad in der Stufe existieren würde, wenn T′′ ausgeführt wird, er während dieser Stufe abgetrennt werden würde, 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′′ ausgeführt worden ist. Deshalb kann nur ein Pfad T′′→. . .→T in CSG_i oder in CSG_j für jeden RM j existieren, wobei j≠i ist. Das heißt, 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 irgendeine nicht entschiedene Transaktion T′ (USG_i) überprü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 RM i muß sie abbrechen (indem er "Nein" über AC wählt). Wenn es keine Kante von T′ nach T gibt, dann wird auch keine Entscheidung betreffend T′ in dieser Stufe ausgeführt.

Die obenstehenden Argumente stellen sicher, daß keine fertige Transaktion eine Verletzung der Serieneigenschaft verursachen kann, wenn sie zu Anfang der induktiven Stufe ausgeführt wird, wie angenommen wurde, und deshalb konnte (irgendeine fertige Transaktion) T ausgeführt werden.

In der CS-Implementation oben werden alle PR-Transaktionen identifiziert und in jeder Stufe abgebrochen. Durch Überprü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 einzig mögliche Abweichung von dieser obenstehenden Implementation ist durch Abbrechen zusätzlicher Transaktionen in jeder Stufe gegeben. Eine solche Abweichung hält noch die erzeugte History in Lokal-CO.

Schlußfolgerung

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

Schlußfolgerung

58. Wenn die RMs eine gleichzeitige Kontrolle nur über eine Kernausführung steuern, dann sind lokales Ausführungsordnen und lokales Wiederherstellen eine notwendige und ausreichende Bedingung für eine (globale) Serienherstellbarkeit und Wiederherstellbarkeit. Diese Schlußfolgerung folgt aus dem Theorem 52.

59. Ein globaler Stillstand ist ein Stillstand, der durch ein gegenseitiges Blockieren von zwei oder mehreren lokalen Untertransaktionen in zumindest zwei unterschiedlichen Transaktionen von zumindest zwei unterschiedlichen RMs verursacht wird. (Bemerkungen: Da ein Ausführungsordnen nicht inhärent blockierend ist, kann es in einer nicht blockierenden Art und Weise z. B. durch Abbrüche oder durch Abbrüche nach Verzögerungen implementiert bzw. bewerkstelligt werden. Wenn die Planer aller RMs in der Umgebung nicht blockierend sind (mit der Ausnahme eines einzigen, der blockierend sein kann), sind die Ausführungen stillstandsfrei.

Einen anderen Weg für die Implementierung von Ausführungsordnen besteht in der Verwendung von blockierenden CO-Bestä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 blockierend 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 Transaktionen an einem globalen Stillstand beteiligt sein. In diesem Fall sind Nachrichten über Kernausführungen nicht ausreichend für eine Stillstandsauflösung und zusätzliche Nachrichten, die das Vorhandensein von Blöcken bzw. Blockierungen signalisieren, sind erforderlich (möglicherweise aufgesetzt (piggy-backed) auf AC-Nachrichten anderer Transaktionen).

Schlußfolgerung

Ausführungsordnen stellt einen Weg zum Erreichen einer globalen Serienherstellbarkeit zur Verfügung, und das auch durch stillstandsfreie Mechanismen. Das erlaubt einen Kompromiß zwischen blockierenden Techniken, die Stillständen unterworfen sind, und nicht blockierenden Implementationen, die stillstandsfrei sind aber kaskadierenden Abbrüchen unterzogen sind. Um eine Serienherstellbarkeit sicherzustellen, sind keine Dienste, aber eine Kernausführung für die Koordination des Transaktionsmagements durch RMs notwendig, wenn jeder RM ein Ausführungsordnen (commitment ordering) unterstützt. Ein Ausführungsordnen ist für eine globale Serienherstellbarkeit jedoch notwendig, wenn nur eine Kernausführung für die RM-Koordination verwendet wird.

Claims

1. Verfahren zum Betreiben eines digitalen Prozessors in einem Vielprozessorverarbeitungssystem, in dem ein globaler Koordinator mit einer Vielzahl von Transaktionsprozessoren mittels "Vorbereitung"- und "Ausführungs"-Befehlen kommuniziert, um Transaktionen zu verarbeiten, die in Konflikt stehende Komponentenoperationen aufweisen können, wobei das Verfahren die folgenden Schritte aufweist:

a) Beginnen der Erzeugung von Ergebnissen der Transaktionen;
b) Bestimmen einer Ausführungsreihenfolge für die Transaktionen, wenn eine der Transaktionen eine erste Operation hat, die mit einer zweiten Operation in einer anderen der Transaktionen in Konflikt steht, wobei die in Konflikt stehenden Operationen eine Durchführungsreihenfolge haben und wobei die Ausführungsreihenfolge die gleiche ist wie die Durchführungsreihenfolge;
c) Eingeben in den Zustandsspeicher des verarbeitenden Systems erzeugte Ergebnisse einer ausgewählten dieser Transaktionen;
d) Abbrechen eines Abbruchsatzes aus Transaktionen, für die die Ausführung der Ausführungsreihenfolge und das Ausführen der einen ausgewählten Transaktionen aus den Transaktionen entgegensteht.

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

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Schritt des Eingebens in den Zustandsspeicher das Ändern des Speicherzustands einen 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ß die ausgewählte Transaktion aus den Transaktionen in Antwort auf ein Ausführungskommando von einem Koordinator ausgewählt 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 b) abgebrochen werden.

8. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Verfahren weiterhin umfaßt den Schritt des Empfangens einer Nachfrage von einem Koordinator, um eine spezifische Transaktion aus den Transaktionen vorzubereiten; den Schritt des Verzögerns einer Bestätigung der Beendigung der Vorbereitung der spezifizierten Transaktion aus den Transaktionen, bis keine der Transaktionen, die noch nicht beim Schritt c) ausgeführt worden sind oder beim Schritt d) abgebrochen worden sind, im Widerspruch zu der vordefinierten Ausführungsreihenfolge sind; den Schritt des Ausführens der spezifizierten Transaktion der Transaktionen.

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

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ß eine Leseoperation einer zweiten Transaktion der Transaktionen Schreibdaten liest, die von einer Schreiboperation einer ersten Transaktion der Transaktionen geschrieben wurden, bevor die erste Transaktion der Transaktionen ausgeführt wird, und daß das Verfahren weiterhin aufweist die Schritte des Abbrechens aller dieser Transaktionen, die von abgebrochenen Transaktionen geschriebene Daten gelesen haben.

12. Verfahren zum Betreiben eines digitalen Computers, um Transaktionen in einem Rechnersystem zu verarbeiten, wobei das Verfahren die folgenden Schritte aufweist:

a) Empfangen von Nachfragen zum Verarbeiten der Transaktionen;
b) Beginnen der Vorbereitung von Ergebnissen der Transaktionen;
c) Bestimmen einer Ausführungsordnung für die Transaktionen, wenn eine Transaktion der Transaktionen eine erste Operation hat, die in Konflikt mit einer zweiten Operation in einer anderen Transaktion der Transaktionen steht, wobei die in Konflikt stehenden Operationen eine Durchführungsreihenfolge haben, und die Ausführungsordnung die gleiche ist wie die Durchführungsreihenfolge, und wobei die Ausführungsordnung durch die Vorbereitung bzw. Erzeugung von Ergebnissen für Transaktionen mit in Konflikt stehenden Operationen bestimmt wird;
d) Speichern von Daten im Speicher, die die Ausführungsordnung bestimmen;
e) Eingeben in den Zustandsspeicher des Rechnersystems von erzeugten Ergebnissen einer ausgewählten Transaktion der Transaktionen;
f) Überprüfen der in dem Speicher gespeicherten Daten, um zu bestimmen, ob eine Ausführung für andere Transaktionen der Transaktionen widersprüchlich zu der Ausführung der ausgewählten Transaktion aus den Transaktionen und zu der Ausführungsordnung der Transaktionen ist, und, wenn die Ausführung für andere Transaktionen aus den Transaktionen widersprüchlich zu der Ausführung der ausgewählten Transaktion aus den Transaktionen und der Ausführungsordnung für die Transaktionen ist, Abbrechen der anderen Transaktionen aus den Transaktionen, für die die Ausführung entgegen der Ausführungsordnung und der Ausführung der ausgewählten Transaktion aus den Transaktionen ist.

13. Verfahren nach Anspruch 15, 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.

14. Verfahren nach Anspruch 12, dadurch gekennzeichnet, daß von einem Koordinator eine Nachfrage empfangen wird, eine spezifizierte Transaktion der Transaktion vorzubereiten, und daß die Anerkennung der Beendigung der Vorbereitung der spezifizierten Transaktion aus den Transaktionen verzögert wird, bis keine der Transaktionen, die bis jetzt weder im Schritt d) ausgeführt noch im Schritt e) abgebrochen wurden, widersprüchlich zu der vordefinierten Ausführungsordnung sind, und daß die spezifizierte Transaktion aus den Transaktionen ausgeführt wird.

15. Verfahren zum Betreiben eines digitalen Computers, um Transaktionen in einem Computersystem zu verarbeiten, wobei das Verfahren die folgenden Schritte aufweist:

a) Empfangen von Nachfragen, um Transaktionen durchzuführen;
b) Durchführungsplanen von Operationen der Transaktionen auf einer Echtzeitbasis, so daß Operationen einiger Transaktionen in Übereinstimmung mit der Verfügbarkeit von Systemelementen des digitalen Computers vor der Ausführung anderer Transaktionen durchgeführt werden;
c) Bestimmen einer Ausführungsreihenfolge für die Transaktionen, wenn eine der Transaktionen aus den Transaktionen eine erste Operation aufweist, die mit einer zweiten Operation in einer anderen Transaktion aus den Transaktionen in Konflikt steht, wobei die in Konflikt stehenden Operationen eine Durchführungsreihenfolge haben, und wobei die Ausführungsreihenfolge die gleiche ist wie die Durchführungsreihenfolge; und
d) Erzwingen der Ausführung von ausgewählten Transaktionen aus den Transaktionen in Übereinstimmung mit der Ausführungsreihenfolge.

16. Digitales Computersystem zum Verarbeiten von Transaktionen, die in Konflikt stehende Komponentenoperationen aufweisen können, in einem Multiprozessorverarbeitungssystem, in dem ein Koordinator mit einer Vielzahl von Transaktionsprozessoren mittel "Vorbereitungs-" und "Ausführungs"-Kommandos kommuniziert, wobei das digitale Computersystem in Kombination aufweist:

a) eine Einrichtung zum Planen der Durchführung von Operationen der Transaktionen auf einer Echtzeitbasis, so daß Operationen von einigen Transaktionen in Übereinstimmung mit der Erhältlichkeit von Systemelementen des digitalen Computersystems durchgeführt werden, bevor andere Transaktionen ausgeführt werden;
b) eine Einrichtung zum Bestimmen einer Ausführungsreihenfolge der Transaktionen, wenn eine Transaktion aus den Transaktionen eine erste Operation hat, die in Konflikt mit einer zweiten Operation einer anderen Transaktion aus den Transaktionen steht, wobei die in Konflikt stehenden Operationen eine Reihenfolge der Durchführung haben, und wobei die Ausführungsreihenfolge die gleiche ist wie die Reihenfolge der Durchführung; und
c) eine Einrichtung zum Erzwingen der Ausführung von ausgewählten Transaktionen aus den Transaktionen in Übereinstimmung mit der Ausführungsreihenfolge, wobei die Einrichtung zum Erzwingen eine Einrichtung zum Verzögern der Ausführung von ausgewählten Transaktionen und eine Einrichtung zum Abbrechen eines Abbruchsatzes der Transaktionen aufweist, für die Ausführung im Gegensatz zu der Ausführungsreihenfolge und der Ausführung der ausgewählten Transaktionen steht.

17. Digitales Computersystem nach Anspruch 16, dadurch gekennzeichnet, daß die Einrichtung zum Verzögern eine Einrichtung zum Abbrechen der ausgewählten Transaktionen nach einer Verzögerung einer vorgegebenen Zeitdauer enthält.

18. Digitales Computersystem nach Anspruch 16 oder Anspruch 17, dadurch gekennzeichnet, daß die Einrichtung zum Verzögern eine Einrichtung zum Verzögern der Bestätigung der Beendigung der Vorbereitung der ausgewählten Transaktionen aufweist, bis keine der Transaktionen, die noch nicht ausgeführt worden sind oder abgebrochen sind, im Gegensatz zu der vorgegebenen Ausführungsreihenfolge und der Ausführung der nachgefragten Transaktion aus den Transaktionen sind.

19. Digitales Computersystem nach Anspruch 16, dadurch gekennzeichnet, daß die Einrichtung zum Bestimmen der Ausführungsreihenfolge eine Einrichtung zum Detektieren der Durchführung einer Operation enthält, die mit einer vorher durchgeführten Operation in Konflikt steht.

20. Digitales Computersystem nach Anspruch 19, dadurch gekennzeichnet, daß die Einrichtung zum Detektieren eine Einrichtung zum Vergleichen einer Adresse einer Speicherzugriffsoperation für eine Transaktion mit den Adressen von Speicherzugriffsoperationen, die vorher für andere Transaktionen durchgeführt worden sind, enthält.

21. Digitales Computersystem nach Anspruch 16, dadurch gekennzeichnet, daß die Einrichtung zum Abbrechen eine Einrichtung zum Abbrechen aller Transaktionen enthält, die Daten gelesen haben, die von abgebrochenen Transaktionen geschrieben worden sind.