DE10123067A1 - Synchrone Vervielfältigung von Transaktionen in einem verteilten System - Google Patents

Abstract

Die Verwaltung und Verwendung von vervielfältigten verteilten Transaktionen werden vereinfacht. Es wird ein Systemprotokoll einer verteilten synchronen Transaktion bereitgestellt, um die Vervielfältigung verteilter Transaktionen für Client-Anwendungsinstanzen zu verwalten. Das verteilte synchrone Transaktionssystem gestattet das Vervielfältigen von Transaktionen, ohne dass die Client-Anwendungsinstanzen andere Instanzen kennen müssen, um die Transaktion zu empfangen. Weiterhin verwaltet das verteilte synchrone Transaktionssystem die Wiederherstellung von einem Fehler, wenn ein Fehler während der Verarbeitung einer verteilten vervielfältigten Transaktion auftritt.

Description

Querverweise auf verwandte Anmeldungen

Diese Anmeldung enthält einen Erfindungsgegenstand, der sich auf den Erfindungsgegenstand der folgenden Anmeldungen bezieht, von denen alle demselben Rechtsnachfolger wie diese Anwendung übertragen wurden, wobei auf jede von ihnen hiermit in ihrer Gesamtheit Bezug genommen wird:
"METHOD, SYSTEM AND PROGRAM PRODUCTS FOR MANAGING PROCESSING GROUPS OF A DISTRIBUTED COMPUTING ENVIRONMENT", Novaes et al., Serien-Nr. 09/584259, eingereicht am 31. Mai 2000.
"METHOD, SYSTEM AND PROGRAM PRODUCTS FOR RECOVERING FROM FAILURES WITHIN A SHARED NOTHING DISTRIBUTED COMPUTING ENVIRONMENT", Novaes et al., Serien-Nr. 09/583784, eingereicht am 31. Mai 2000.
"METHOD, SYSTEM AND PROGRAM PRODUCTS FOR SERIALIZING REPLICATED TRANSACTIONS OF A DISTRIBUTED COMPUTING ENVIRONMENT", Novaes et al., Serien-Nr. 09/584481, eingereicht am 31. Mai 2000; und
"METHOD, SYSTEM AND PROGRAM PRODUCTS FOR MANAGING A CLUSTERED COMPUTING ENVIRONMENT", Novaes et al., Serien-Nr. 09/583677, eingereicht am 31. Mai 2000.

Technisches Gebiet

Diese Erfindung bezieht sich allgemein auf verteilte Systeme und insbesondere auf die Verwaltung eines verteilten synchronen Transaktionssystems.

Vorgeschichte

Verteilte Systeme sind skalierbare Systeme mit hoher Verfügbarkeit, die in verschiedenen Situationen verwendet werden, einschließlich solcher Situationen, die einen hohen Arbeitsdurchsatz oder ununterbrochene oder fast ununterbrochene Verfügbarkeit des Systems erfordern.

Ein Typ eines verteilten Systems ist ein verteiltes synchrones Transaktionssystem, ein System, das verteilte synchrone Transaktionen im Namen verteilter Clients ausführt. Eine verteilte synchrone Transaktion ist eine Transaktion, die im Wesentlichen sofort eingeleitet wird, wenn sie von einer Client- Anwendung angefordert wird, und die wiederum im Wesentlichen sofort nach dem Abschluss der Transaktion über den Erfolg der Transaktion benachrichtigt wird.

Obwohl es heute Einrichtungen zur Verwaltung verteilter synchroner Transaktionen gibt, neigen diese Einrichtungen zur Kompliziertheit. Somit gibt es noch einen Bedarf nach Möglichkeiten, die Verwaltung von synchronen Transaktionen in einem verteilten System zu erleichtern.

Zusammenfassung der Erfindung

Die Unzulänglichkeiten des Standes der Technik werden überwunden und zusätzliche Vorteile werden bereitgestellt, indem ein Verfahren zur Ausführung synchroner Vervielfältigung von Transaktionen einer verteilten Rechnerumgebung bereitgestellt wird. Das Verfahren beinhaltet zum Beispiel das Einleiten einer Transaktion innerhalb der verteilten Rechnerumgebung durch eine Instanz einer Client-Anwendung der verteilten Rechnerumgebung; und das Vervielfältigen der Transaktion zu mindestens einer anderen Instanz der Client-Anwendung, wobei das Vorhandensein der anderen Instanz vor der Instanz verborgen wird, welche die Transaktion einleitete.

System und Computerprogrammprodukte entsprechend den oben zusammengefassten Verfahren werden hierin ebenfalls beschrieben und beansprucht.

Durch die Techniken der vorliegenden Erfindung werden zusätzliche Merkmale und Vorteile ausgeführt. Andere Ausführungsformen und Aspekte der Erfindung werden hierin im Einzelnen beschrieben und als Teil der beanspruchten Erfindung betrachtet.

Kurze Beschreibung der Zeichnungen

Der Erfindungsgegenstand wird in den Ansprüchen am Ende der Spezifikation speziell ausgeführt und deutlich beansprucht. Die vorhergenannten und andere Aufgaben, Merkmale und Vorteile der Erfindung werden aus der folgenden ausführlichen Beschreibung in Verbindung mit den beiliegenden Zeichnungen ersichtlich, in denen:

Fig. 1 ein Beispiel einer Rechnerumgebung zeigt, die Aspekte der vorliegenden Erfindung einbezieht und verwendet;

Fig. 2 ein Beispiel verschiedenen Komponenten von mehreren Netzknoten von Fig. 1 gemäß einem Aspekt der vorliegenden Erfindung zeigt;

Fig. 3 eine Ausführungsform einer Rechnerumgebung zeigt, in der eine Client-Anwendungsinstanz auf eine Anforderung einer Drittanwendung gemäß einem Aspekt der vorliegenden Erfindung antwortet, ohne einen DSTS-Server zu verwenden;

Fig. 4 eine Ausführungsform einer Rechnerumgebung zeigt, in der eine Client-Anwendungsinstanz einen DSTS-Server verwendet, um auf eine Anforderung der Anwendung einer dritten Partei gemäß einem Aspekt der vorliegenden Erfindung zu antworten;

Fig. 5 ein Beispiel der Verarbeitungsgruppe zeigt, die gemäß einem Aspekt von vorliegenden Erfindung verwendet wird;

Fig. 6a ein Beispiel der Komponenten zeigt, die einem Gruppenaktivierungsprotokoll gemäß einem Aspekt der vorliegenden Erfindung zugeordnet sind;

Fig. 6b-6d eine Ausführungsform der Logik zeigen, der dem Ausführen der Gruppenaktivierung gemäß einem Aspekt der vorliegenden Erfindung zugeordnet ist;

Fig. 7 ein Beispiel der Felder zeigt, die einer Initialisierungsnachricht gemäß einem Aspekt der vorliegenden Erfindung zugeordnet sind;

Fig. 8 eine Ausführungsform der Komponenten zeigt, die einem Gruppenverknüpfungsprotokoll gemäß einem Aspekt der vorliegenden Erfindung zugeordnet sind;

Fig. 9a-9b eine Ausführungsform der Logik zeigen, der dem Verknüpfen einer Verarbeitungsgruppe gemäß einem Aspekt der vorliegenden Erfindung zugeordnet ist;

Fig. 10 ein Beispiel der Felder zeigt, die einer Stilllegungsnachricht gemäß einem Aspekt der vorliegenden Erfindung zugeordnet sind;

Fig. 11 eine Ausführungsform der Felder zeigt, die einer Archivierungsnachricht gemäß einem Aspekt der vorliegenden Erfindung zugeordnet sind;

Fig. 12 eine Ausführungsform der Felder zeigt, die einer Dearchivierungsnachricht gemäß einem Aspekt der vorliegenden Erfindung zugeordnet sind;

Fig. 13 ein Beispiel der Felder enthält, die einer Aufzählungskennzeichennachricht gemäß einem Aspekt der vorliegenden Erfindung zugeordnet sind;

Fig. 14 ein Beispiel der Felder zeigt, die einer Kennzeichenaufzählungsnachricht gemäß einem Aspekt der vorliegenden Erfindung zugeordnet sind;

Fig. 15 eine Ausführungsform der Logik zeigt, der dem Ausschließen eines Mitglieds von einer Verarbeitungsgruppe gemäß einem Aspekt der vorliegenden Erfindung zugeordnet ist;

Fig. 16 ein Beispiel der Felder zeigt, die einer Quorumhinweisnachricht gemäß einem Aspekt der vorliegenden Erfindung zugeordnet sind;

Fig. 17 ein Beispiel der Felder zeigt, die einer Vervielfältigungsanforderungsnachricht gemäß einem Aspekt der vorliegenden Erfindung zugeordnet sind;

Fig. 18 ein Beispiel der Felder zeigt, die einer Vervielfältigungsrückrufnachricht gemäß einem Aspekt der vorliegenden Erfindung zugeordnet sind;

Fig. 19 ein Beispiel der Felder zeigt, die einer Vervielfältigungsrückrufergebnisnachricht gemäß einem Aspekt der vorliegenden Erfindung zugeordnet sind;

Fig. 20 ein Beispiel der Felder zeigt, die einer Vervielfältigungsabschlussnachricht gemäß einem Aspekt der vorliegenden Erfindung zugeordnet sind;

Fig. 21 ein Beispiel der Felder zeigt, die einer Systemabschaltnachricht gemäß einem Aspekt der vorliegenden Erfindung zugeordnet sind;

Fig. 22a-22b eine Ausführungsform des Nachrichtenflusses zeigen, welcher der Verarbeitung einer synchronen Transaktion gemäß einem Aspekt der vorliegenden Erfindung zugeordnet ist;

Fig. 23 eine Ausführungsform des Nachrichtenflusses zeigt, der einer Vorbereiten-zum-Festschreiben-Operation gemäß einem Aspekt der vorliegenden Erfindung zugeordnet ist;

Fig. 24 eine Ausführungsform des Nachrichtenflusses zeigt, der einer Festschreibeoperation gemäß einem Aspekt der vorliegenden Erfindung zugeordnet ist;

Fig. 25 ein Beispiel einer Momentaufnahme eines verteilten Systems zu einem bestimmten Zeitpunkt gemäß einem Aspekt der vorliegenden Erfindung zeigt; und

Fig. 26 eine Ausführungsform der Logik zeigt, der einer Wiederherstellungsprozedur gemäß einem Aspekt der vorliegenden Erfindung zugeordnet ist.

Bester Modus zum Ausführen der Erfindung

Gemäß den Aspekten der vorliegenden Erfindung werden verteilte synchrone Transaktionen ausgeführt und verwaltet. Die verteilten synchronen Transaktionen werden von verteilten Client- Anwendungen einer verteilten Rechnerumgebung verwendet.

Ein Beispiel einer verteilten Rechnerumgebung, die Aspekte der vorliegenden Erfindung einbezieht und verwendet, wird in Fig. 1 gezeigt und hierin beschrieben. Eine verteilte Rechnerumgebung 100 enthält zum Beispiel eine Vielzahl von Rahmen 102, die miteinander über eine Vielzahl von LAN-Überleitungseinrichtungen 104 verbunden sind. Die Rahmen 102 und LAN- Überleitungseinrichtungen 104 werden weiter unten im einzelnen beschrieben.

In einem Beispiel enthält die verteilte Rechnerumgebung 100 acht (8) Rahmen, von denen jeder eine Vielzahl von Verarbeitungsnetzknoten 106 enthält. In einem Beispiel enthält jeder Rahmen sechzehn (16) Verarbeitungsnetzknoten (wobei jeder einen oder mehrere Prozessoren aufweist). Jeder Verarbeitungsnetzknoten ist zum Beispiel ein RISC/6000 Computer unter AIX, einem UNIX-basierten Betriebssystem. Jeder Verarbeitungsnetzknoten innerhalb eines Rahmens ist mit den anderen Verarbeitungsnetzknoten des Rahmens beispielsweise über eine interne LAN-Verbindung verbunden. Zusätzlich wird jeder Rahmen über die LAN-Überleitungseinrichtungen 104 mit den anderen Rahmen verbunden.

Beispielsweise enthält jedes LAN-Überleitungseinrichtungen 104 entweder einen RISC/6000-Computer, irgendeine Computernetzwerkverknüpfung zum LAN oder ein Netzleitwegprogramm. Dies sind jedoch nur Beispiele. Es wird für den Fachmann ersichtlich sein, dass es andere Typen von LAN- Überleitungseinrichtungen gibt und dass auch andere Mechanismen verwendet werden können, um die Rahmen miteinander zu verknüpfen.

Die verteilte Rechnerumgebung von Fig. 1 ist nur ein Beispiel. Es ist möglich, mehr oder weniger als acht Rahmen oder mehr oder weniger als sechzehn Netzknoten pro Rahmen zu haben. Weiterhin müssen die Verarbeitungsnetzknoten keine RISC/6000-Computer unter AIX sein. Einige oder alle der Verarbeitungsnetzknoten können andere Typen von Computern und/oder andere Betriebssysteme enthalten. Weiterhin kann eine heterogene Umgebung die Erfindung einschließen und verwenden, in der ein oder mehrere der Netzknoten und/oder Betriebssysteme der Umgebung von anderen Netzknoten oder Betriebssystemen der Umgebung verschieden sind. Die Netzknoten einer derartigen heterogenen Umgebung arbeiten zusammen, indem sie zusammenwirken und Ressourcen gemeinsam benutzen, wie hierin beschrieben.

Weitere Einzelheiten hinsichtlich der Netzknoten einer verteilten Computerumgebung werden mit Bezug auf Fig. 2 beschrieben. In einem Beispiel wird eine verteilte Client- Anwendung 200 auf einer Vielzahl von Netzknoten 202 ausgeführt. Insbesondere wird eine Instanz der Client-Anwendung weitgehend gleichzeitig auf jedem der Vielzahl von Netzknoten ausgeführt, die in diesem speziellen Beispiel drei Netzknoten enthält. (Der Fachmann wird erkennen, dass die Client-Anwendung auf irgendeiner Anzahl von Netzknoten der Umgebung einschließlich nur eines Netzknotens ausgeführt werden kann.)

In einer Ausführungsform werden die Client-Anwendungsinstanzen mit einem verteilten synchronen Transaktionssystem (distributed synchronous transaction system, DSTS) verbunden, das die Anwendungsinstanzen gemäß einem Aspekt der vorliegenden Erfindung aktiviert, um an der synchronen Vervielfältigung von Transaktionen teilzunehmen. Durch Verwenden des verteilten synchronen Transaktionssystems kann eine Client-Instanz an der synchronen Vervielfältigung von Transaktionen teilnehmen, sogar wenn die Client-Anwendungsinstanz kein direktes Wissen über irgendwelche anderen Instanzen der Anwendung hat. Das verteilte synchrone Transaktionssystem enthält eine oder mehrere DSTS- Instanzen (z. B. Computerprogramme) 204, die auf einem oder mehreren Netzknoten ausgeführt werden. In einem Beispiel wird eine DSTS-Instanz auf jedem Netzknoten ausgeführt, der eine Client-Anwendungsinstanz hat, die daran interessiert ist, an einer verteilten Transaktion teilzunehmen. Jede DSTS-Instanz wird mit einer oder mehreren Instanzen von einer oder mehreren Client-Anwendungen verbunden.

Wenn die DSTS-Instanz in den Speicher eines Netzknotens geladen und ausgeführt wird, wird sie als ein Serverprozess wahrgenommen, der seinem entsprechenden Client-Anwendungsprozess (oder Prozessen) dient. Das DSTS-System führt eine verteilte synchrone Transaktion im Namen einer Client-Anwendung aus. Wenn die Transaktion durch den Client angefordert wird, wird sie im Wesentlichen sofort durch einen DSTS-Server eingeleitet. Weiterhin wird der Client nach Abschluss der Transaktion im Wesentlichen sofort über das Ergebnis (z. B. Erfolg, Fehler) der Transaktion benachrichtigt.

Eine Sammlung einer oder mehrerer Client-Anwendungsinstanzen, die an der Ausführung einer verteilten synchronen Transaktion teilnehmen, wird als eine vervielfältigte Gruppe von Client- Anwendungsinstanzen bezeichnet. Diese Gruppe unterscheidet sich von anderen Formen von Gruppen in einem verteilten System, da die Mitglieder der vervielfältigten Gruppe kein direktes Wissen voneinander haben. Stattdessen wird die Gruppe implizit gebildet, wenn eine Client-Anwendungsinstanz einen Fluss von Aktualisierungsoperationen umleitet, um an einer anderen Client- Anwendungsinstanz oder mehreren anderen Client- Anwendungsinstanzen vervielfältigt zu werden.

Insbesondere leitet die Client-Anwendung den Fluss von Operationen um, die ihren permanenten (gespeicherten) oder Laufzeit- (nicht gespeicherten) Status modifizieren. Diese Aktualisierungsoperationen werden als Schreiboperationen klassifiziert. Irgendeine andere Transaktion, die den Status der Client-Anwendung nicht modifiziert, kann als eine Abfrage- oder Lesetransaktion bezeichnet werden. Gemäß einem Aspekt der vorliegenden Erfindung führen Client-Anwendungen Schreiboperationen als verteilte synchrone Transaktionen aus, die jeder Kopie der Client-Anwendung einen konsistenten oder identischen Status liefern. Eine derartige Fähigkeit macht es wiederum möglich, für irgendeine Kopie der Anwendung auf Abfragen (Leseoperationen) zu ihrem Status zu antworten, ohne die Abfrage an irgendeine der anderen Nachbildungen umleiten zu müssen. Anders gesagt, Client-Anwendungen können Leseoperationen lokal bedienen, ohne einen DSTS-Server zu verwenden (siehe Fig. 3), während Schreiboperationen an andere Instanzen der Client- Anwendung vervielfältigt werden und somit das DSTS verwenden (siehe Fig. 4), wie unten in weiteren Einzelheiten beschrieben wird. Diese Architektur ist optimal für leseintensive Systeme und Systeme, die eine niedrige Rate von Schreiboperationen zeigen, jedoch nicht auf diese beschränkt.

Der Fluss von Aktualisierungsoperationen wird durch eine Client- Anwendung zum Beispiel über ein DSTS Protokoll umgeleitet, das von der Client-Anwendung verwendet wird. Ein Merkmal dieses Protokolls enthält gemäß einem Aspekt der vorliegenden Erfindung die Mitgliedschaft in einer oder mehreren Verarbeitungsgruppen. Eine Verarbeitungsgruppe 500 (Fig. 5) enthält ein oder mehrere Mitglieder 502. In diesem Beispiel ist jedes Mitglied ein DSTS- Server. So gibt es für jede Client-Anwendungsinstanz einer vervielfältigten Gruppe einen entsprechenden DSTS-Server in einer gegebenen Verarbeitungsgruppe (auch bekannt als eine Gruppe). Wenn zum Beispiel eine vervielfältigte Gruppe Client- Anwendungsinstanzen A und B enthält, dann enthält eine Verarbeitungsgruppe DSTS-Server A und B, die mit den Anwendungsinstanzen A beziehungsweise B verbunden sind. Dies gestattet der Verarbeitungsgruppe, die Vervielfältigung von Transaktionen für die Client-Anwendungen der vervielfältigten Gruppe zu bearbeiten und ermöglicht, dass die Vervielfältigung jenen Client-Anwendungen transparent wird.

Jedem Mitglied einer Verarbeitungsgruppe wird eine konsistente Sicht der Gruppenstatusdaten gesichert. Die Daten werden konsistent gehalten, da sie nur durch gut definierte Gruppenprotokolle aktualisiert werden. Beispiele der Protokolle enthalten Aufnahme in eine Gruppe, einschließlich Aktivierung der Gruppe und Verknüpfen der Gruppe, und Ausschluss von der Gruppe, die alle weiter unten detailliert beschrieben werden. Weitere Einzelheiten hinsichtlich der Verwaltung einer Verarbeitungsgruppe werden in der US-Patentschrift No. 5 748 958 mit dem Titel "System For Utilizing Batch Requests To Present Membership Changes To Process Groups" besprochen, veröffentlicht am 5. Mai 1998, auf die hiermit in ihrer Gesamtheit Bezug genommen wird.

Eine Ausführungsform der Logik, die dem Eintritt in eine Gruppe zugeordnet ist, wird mit Bezug auf die Fig. 6a-6d beschrieben. Insbesondere zeigt Fig. 6a ein Beispiel der Komponenten, die am Aktivieren einer Gruppe beteiligt sind; und Fig. 6b-6d zeigen eine Ausführungsform der Logik. Im anfänglichen Fall der Gruppenaktivierung gibt es keine Mitglieder in der Verarbeitungsgruppe. Es wird angenommen, dass die Gruppe vorher definiert wurde, aber keine der Kopien (d. h. DSTS) der Gruppe zur Zeit ausgeführt wird. Die Ausführung einer DSTS-Kopie beginnt, wenn sie mit einer Client-Anwendung verbunden wird.

In einem Beispiel verbindet eine Client-Anwendung 602 einen DSTS-Server 604 über eine Initialisierungsnachricht, SCHRITT 600 (Fig. 6a, 6b). Die Initialisierungsnachricht wird von der Client-Anwendungsinstanz 602 an den DSTS-Server 604 gesendet, um ihn mit dem DSTS-System zu verbinden. Insbesondere verbindet sich in einem Beispiel die Client-Anwendungsinstanz mit dem DSTS-Server auf demselben Netzknoten wie die Client- Anwendungsinstanz. Ein Beispiel der Initialisierungsnachricht wird mit Bezug auf Fig. 7 beschrieben.

Eine Initialisierungsnachricht 700 enthält zum Beispiel einen Operationscode 702, der den Typ der Operation kennzeichnet (z. B. Initialisieren), die angefordert wurde, und einen Namen 704 der Client-Anwendung, welche die Anforderung absetzt. Das DSTS- System verwendet den Anwendungsnamen, um Transaktionen an die anderen Instanzen der Anwendung (d. h. die Mitglieder der vervielfältigten Gruppe) mit demselben Namen weiterzuleiten.

Es wird nochmals auf Fig. 6a-6b Bezug genommen, als Antwort auf diese Nachricht schlägt der DSTS-Server vor, in eine Gruppe einzutreten (gekennzeichnet durch Anwendungsname 704 (Fig. 7), SCHRITT 606 (Fig. 6b)). Wenn er vorschlägt, in die Gruppe einzutreten, liest der DSTS-Server den Gruppenstatus vom permanenten Speicher 608 (Fig. 6a). Der Gruppenstatus 610 enthält zum Beispiel die Gruppenfolgenummer und den Aktivierungsstatus. Wenn der Gruppenstatus aktiv ist, ABFRAGE 612 (Fig. 6b), führt die eintretende Kopie ein Eintrittsprotokoll aus, SCHRITT 614, wie unten beschrieben. Anderenfalls ist der Status inaktiv, und die Kopie kann der Gruppe sofort beitreten, ohne das unten definierte Eintrittsprotokoll auszuführen, SCHRITT 616.

Wenn der DSTS-Server in die Gruppe eintritt, vergleicht die Kopie die Gruppenreihenfolgenummer mit ihrer eigenen Reihenfolgenummer, SCHRITT 618. Wenn die Gruppenreihenfolgenummer kleiner als ihre eigene ist, aktualisiert die Kopie die Gruppenreihenfolgenummer, SCHRITT 620. Danach, oder wenn die Gruppenreihenfolgenummer gleich oder größer als die Reihenfolgenummer der Kopie ist, erfolgt eine Feststellung, ob (in diesem Beispiel) ein Quorum von Mitgliedern erreicht wurde, ABFRAGE 622.

Wenn kein Quorum erreicht wurde, fährt die Verarbeitung mit SCHRITT 600 für ein anderes Mitglied fort, bis mindestens ein Quorum erreicht wird. Da ein Quorum von Mitgliedern der Gruppe beitritt, wissen die Kopien, die Mitglieder der Verarbeitungsgruppe sind, dass das Quorum erreicht wurde. An diesem Punkt wird die Gruppenreihenfolgenummer auf den höchsten Mitgliederbestand gesetzt, SCHRITT 624. Die Mitglieder, deren Reihenfolgenummer mit der der Gruppe übereinstimmt, wenn dieser Punkt erreicht wird, leiten ein Aktivierungsprotokoll durch Senden einer Gruppenaktivierungsnachricht ein, SCHRITT 626. Die Gruppenaktivierungsnachricht leitet ein Mehrphasenprotokoll ein.

In der ersten Phase der Aktivierung empfangen die Mitglieder der Gruppe die Gruppenaktivierungsnachricht, welche die Knotenadresse des Mitglieds enthält, das die Nachricht gesendet hat, SCHRITT 628 (Fig. 6c). Dann bitten die Mitglieder der aktuellen Gruppe, deren Reihenfolgenummern kleiner als die Reihenfolgenummer der aktuellen Gruppe sind, den Absender der Aktivierungsnachricht um eine Kopie des Gruppenstatus, die der Reihenfolgenummer der Gruppe zugeordnet ist, SCHRITT 630. Diese Mitglieder initialisieren sich selbst erneut unter Verwendung des neuen Gruppenstatus, SCHRITT 632, und schlagen dann vor, mit der zweiten Phase der Gruppenaktivierung fortzufahren, SCHRITT 634. Ein Mitglied, dessen Initialisierung scheitert, stimmt an diesem Punkt für den Abbruch des Protokolls.

Die Mitglieder, deren Reihenfolgenummern mit denen der Gruppe übereinstimmen, schlagen auch vor, zur zweiten Phase zu gehen. Wenn alle aktuellen Mitglieder vorschlagen, zur zweiten Phase zu gehen (keine Abbrüche), beginnt die zweite Phase.

Wenn die erste Phase der Gruppenaktivierung endet, prüfen die aktuellen Mitglieder der Verarbeitungsgruppe, ob eine Mehrzahl der Mitglieder aufrechterhalten wurde, SCHRITT 636 (Fig. 6d). Weiterhin hat nun jedes Mitglied dieselbe konsistente Reihenfolgenummer und Kopie des verteilten Status.

Die Mitglieder ändern jetzt die Gruppenreihenfolgenummer, indem sie z. B. 1 dazuaddieren, SCHRITT 638. Die Mitglieder speichern dann die neue Reihenfolgenummer im Gruppenstatus und schlagen vor, das Protokoll zu schließen, SCHRITT 640. Ein Mitglied, das auf dieser Stufe scheitert, schlägt vor, das Protokoll abzubrechen.

Wenn bei Protokollabschluss kein aktuelles Mitglied abgebrochen hat, ABFRAGE 642, hat die Gruppe die Garantie, dass die aktuellen Mitglieder der Gruppe denselben konsistenten Gruppenstatus und Reihenfolgenummer haben und dass die neue Reihenfolgenummer von einer Mehrzahl der Mitglieder der Gruppe gespeichert wurde. Der Gruppenstatus wird dann zu aktiv geändert, SCHRITT 644.

Jedesmal, wenn ein Mitglied einer aktiven Gruppe beitritt, leitet es ein Mehrphasengruppeneintrittsprotokoll ein, wovon eine Ausführungsform mit Bezug auf die Fig. 8 und 9a-9b beschrieben wird. Insbesondere zeigt Fig. 8 die Komponenten des Beitrittsprozesses, während die Fig. 9a-9b eine Ausführungsform der Logik zeigen. In der ersten Phase des Protokolls sendet das eintretende Mitglied (800 von Fig. 8) eine Eintrittsvorschlagsnachricht mit der Reihenfolgenummer, die es aus dem permanenten Speicher abgerufen hat, oder negativ Unendlich, wenn es nicht in der Lage war, die Reihenfolgenummer abzurufen, SCHRITT 900 (Fig. 9a). Beispielsweise können sowohl die Reihenfolgenummer als auch andere Gruppenstatus nicht verfügbar sein, wenn die Platte, auf welcher der Status gespeichert wurde, zerstört oder anderweitig nicht verfügbar ist oder wenn die Kopie des Mitglieds unter irgendeinem bestimmtem Prozessor tatsächlich erstmalig ausgeführt wird.

Als Antwort auf das Empfangen der Eintrittsvorschlagsnachricht unterbrechen die anderen Mitglieder der Gruppe (802, Fig. 8) Aktualisierungen auf den verteilten Daten, SCHRITT 902. In einer Ausführungsform sendet jedes Mitglied der Gruppe seiner entsprechenden Client-Anwendungsinstanz eine Stilllegungsnachricht, um die Aktualisierungen einzustellen. Ein Beispiel für die Stilllegungsnachricht wird mit Bezug auf Fig. 10 beschrieben. Eine Stilllegungsnachricht 1000 enthält zum Beispiel einen Operationscode 1002, der kennzeichnet, dass dies eine Stilllegungsoperation ist. Die Stilllegungsnachricht fordert die Client-Anwendungen auf, das Senden von Aktualisierungsanforderungen zu beenden (z. B. Vervielfältigungsanforderungsnachrichten, wie unten beschrieben), so dass der globale Status der Anwendung stabilisiert wird.

Danach wird jede Kopie der Anwendung aufgefordert, eine Momentaufnahme des aktuellen Status der Anwendung zu erzeugen und diesen Status im permanenten Speicher zu speichern, SCHRITT 904. Diese Anforderung wird durch Senden einer Archivnachricht an die Kopien der Anwendung ausgeführt. Ein Beispiel einer Archivnachricht wird mit Bezug auf Fig. 11 beschrieben. In einem Beispiel enthält eine Archivnachricht 1100 einen Operationscode 1102, der kennzeichnet, dass dies eine Archivanforderung ist.

Alle Mitglieder empfangen eine Kopie des Eintrittsvorschlags, einschließlich des eintretenden Mitglieds. Das eintretende Mitglied vergleicht dann die Reihenfolgenummer des Vorschlags mit der derzeitigen Gruppenmitgliedschaft oder negativ Unendlich, wenn keine anderen Mitglieder Teil der Gruppe sind, ABFRAGE 906. Wenn die Reihenfolgenummer des eintretenden Mitglieds kleiner als die Reihenfolgenummer der Gruppe ist, erfolgt eine Feststellung, ob die Gruppe aktiv ist, ABFRAGE 908. In einem Beispiel erfolgt diese Feststellung durch Prüfen des Aktivierungsstatus im Gruppenstatus (804, Fig. 8).

Wenn die Gruppe noch aktiv ist, stellt das eintretende Mitglied Kontakt zu einem der Mitglieder her, das die größere Reihenfolgenummer hat, und fragt den permanenten Status des verteilten Systems von dem Netzknoten dieses Mitglieds ab und verschiebt ihn zum Anwendungsspeicherbereich, SCHRITT 910. Insbesondere in einem Beispiel verwendet das DSTS-System eine Dearchivierungsnachricht, um die Momentaufnahme vom Speicher abzurufen und die überholte Kopie der Anwendung aufzufordern, die zuletzt aktualisierte Momentaufnahme zu laden.

Ein Beispiel der Dearchivierungsnachricht wird mit Bezug auf Fig. 12 beschrieben. Eine Dearchivierungsnachricht 1200 enthält einen Operationscode 1202, der kennzeichnet, dass dies eine Dearchivierungsnachricht ist, und ein Archivpositionsfeld 1204, das zeigt, von wo die Daten abgerufen werden sollen.

Zusätzlich zum Absetzen der Dearchivierungsnachricht setzt der DSTS-Server auch eine Aufzählungskennzeichennachricht ab, die zum Beispiel sofort ausgeführt wird, nachdem die Client- Anwendung eine Momentaufnahme des permanenten Status lädt. Eine Aufzählungskennzeichennachricht 1300 (Fig. 13) enthält zum Beispiel einen Operationscode 1302, der anzeigt, dass dies eine Aufzählungskennzeichennachricht ist. Nach Empfang dieser Nachricht sendet die Client-Anwendung dem DSTS-System eine Kennzeichenaufzählungsnachricht zurück, welche die Namen der Ressourcen, welche die Anwendung erzeugt hat, den Ressourcenkennzeichen zuordnet.

Ein Beispiel der Kennzeichenaufzählungsnachricht wird mit Bezug auf Fig. 14 beschrieben und enthält zum Beispiel einen Operationscode 1402, der kennzeichnet, dass dies die Kennzeichenaufzählungsnachricht ist, und eine Ressourcenkennzeichenzuordnung 1404, die ein oder mehrere Paare von Ressourcennamen und Kennzeichen enthält. Diese Kennzeichen sind eindeutige Namen, die zum Beispiel verwendet werden, um Anwendungen von dritten Parteien über Änderungen des Status der Client-Anwendung zu benachrichtigen und gleichzeitige Aktualisierungsanforderungen an dieselben Ressourcen zu serialisieren, wie unten beschrieben.

Nach erfolgreichem Neuinitialisieren ihrer selbst durch Laden der Momentaufnahme wird der neuen Kopie gestattet, am DSTS- System teilzunehmen, und es wird eine Zusammenfassungsnachricht an alle Kopien gesendet, so dass das DSTS-System seinen normalen Betrieb wiederaufnehmen kann. Weiterhin schlägt die neue Kopie vor, die zweite Phase des Eintretens zu beginnen, SCHRITT 912.

Es wird auf ABFRAGE 908 Bezug genommen, wenn die Gruppe inaktiv wird, bemerkt das eintretende Mitglied die Tatsache, dass seine Reihenfolgenummer überholt ist, SCHRITT 916, und wartet auf eine Aktivierungsnachricht für weitere Aktionen, SCHRITT 918. Das eintretende Mitglied nimmt an dieser zweiten Phase der Verknüpfung nicht teil.

Es wird auf ABFRAGE 906 Bezug genommen, wenn die Reihenfolgenummer des eintretenden Mitglieds gleich der Reihenfolgenummer der Gruppe ist, ist die Gruppe inaktiv. Diese Tatsache ist aufgrund des Gruppenaktivierungsprotokolls (z. B. in diesem Beispiel eine Quorum-Politik) und durch die Eigenschaft der Quorum-Durchsetzung gegeben. So wartet das eintretende Mitglied, dass sich eine Aktivierungsnachricht auswirkt, SCHRITT 918, und es gibt keine zweite Eintrittsphase. Ähnlich folgt auch, wenn die Reihenfolgenummer des eintretenden Mitglieds größer ist, ABFRAGE 906, dass die Gruppe inaktiv ist, und so wartet das eintretende Mitglied auf eine Aktivierungsnachricht, SCHRITT 918.

Wenn das eintretende Mitglied vorgeschlagen hat, zur zweiten Phase überzugehen, hat es die neue Reihenfolgenummer und den verteilten Status. So ändern nun die Mitglieder (einschließlich des eintretenden Mitglieds) die Gruppenreihenfolgenummer, indem sie zum Beispiel eins addieren, SCHRITT 922 (Fig. 9b). Die Mitglieder speichern dann die neue Reihenfolgenummer und den Gruppenstatus, SCHRITT 924, und schlagen weiterhin vor, das Protokoll zu schließen, SCHRITT 926. Irgendein Mitglied, das auf dieser Ebene scheitert, schlägt vor, das Protokoll abzubrechen. Wenn kein Mitglied abbricht, wird der Gruppe garantiert, dass die aktuellen Mitglieder der Gruppe denselben konsistenten Gruppenstatus und Reihenfolgenummer haben und dass die neue Reihenfolgenummer für eine Mehrzahl von Mitgliedern der Gruppe gespeichert wurde.

Zusätzlich zu Obengenanntem kann ein Mitglied aus einer Gruppe ausgeschlossen werden. Insbesondere bemerken die verbleibenden Mitglieder der Gruppe jedesmal, wenn ein Knoten oder die DSTS- Kopie, die auf dem Netzknoten ausgeführt wird, scheitert, dass ein Mitglied gescheitert ist, SCHRITT 1500 (Fig. 15). Wenn die Gruppe inaktiv ist, ABFRAGE 1502, wird keine Aktion ausgeführt, SCHRITT 1504. Wenn weiterhin die Gruppe aktiv ist, aber keine Mehrzahl von Mitgliedern hat, ABFRAGE 1506, wird keine Aktion ausgeführt.

Wenn die Gruppe jedoch aktiv ist und die Mehrheit behält, ABFRAGE 1506, stoppt jedes Mitglied alle weiteren Aktualisierungen am verteilten Status, SCHRITT 150. Zusätzlich ändert jedes Mitglied die Gruppenreihenfolgenummer, beispielsweise durch Addieren von 1, SCHRITT 1508, und lädt die neue Reihenfolgenummer und den Gruppenstatus, SCHRITT 1510. Dann schlagen die Mitglieder vor, das Protokoll zu schließen, SCHRITT 1512. Jedes Mitglied, das auf dieser Stufe scheitert, schlägt vor, das Protokoll abzubrechen.

Wenn kein Mitglied abbricht, hat die Gruppe eine Garantie, dass die aktuellen Mitglieder der Gruppe denselben konsistenten Gruppenstatus und Reihenfolgenummer haben, und dass die neue Reihenfolgenummer durch eine Mehrzahl von Mitgliedern der Gruppe gespeichert wurde.

Das DSTS-System benachrichtigt die Client-Anwendungsinstanzen, wenn ein Quorum (Mehrzahl) von DSTS-Servern verfügbar ist oder verloren wurde, beispielsweise durch Verwenden einer Quorumhinweisnachricht. In einem Beispiel enthält eine Quorumhinweisnachricht 1600 (Fig. 16) einen Operationscode 1602, und die Quoruminformation 1604 zeigt an, ob die Gruppe ein Quorum hat.

Wie hier beschrieben, werden Mitglieder einer Verarbeitungsgruppe verwendet, um verteilte synchrone Transaktionen zu vervielfältigen, die durch Client- Anwendungsinstanzen eingeleitet werden, die mit den Mitgliedern der Gruppe verbunden sind. Um die Übertragung zwischen den Client-Instanzen und den Server-Mitgliedern der Gruppe zu unterstützen, werden verschiedene Nachrichten verwendet. In einem Beispiel enthalten diese Nachrichten (zusätzlich zu den oben beschriebenen Nachrichten) eine Vervielfältigungsanforderungsnachricht, eine Vervielfältigungsrückrufnachricht, eine Vervielfältigungsrückrufergebnisnachricht, eine Vervielfältigungsabschlussnachricht und eine Systemabschlussnachricht, die alle weiter unten beschrieben werden.

Ein Beispiel einer Vervielfältigungsanforderungsnachricht wird mit Bezug auf Fig. 17 beschrieben. Eine Vervielfältigungsanforderungsnachricht 1700 ist eine Nachricht, welche die verteilte Transaktion einleitet. In einem Beispiel enthält sie einen Operationscode 1702, der zeigt, dass dies eine Vervielfältigungsanforderungsnachricht ist; eine Liste der neuen Ressourcennamen 1704, die erzeugt werden, wenn vorhanden; eine exklusive Zugriffsgruppe 1706, die null oder mehr exklusive Ressourcen der Client-Anwendung kennzeichnet; eine gemeinsam verwendete Zugriffsgruppe 1708, die null oder mehr gemeinsam verwendete Ressourcen der Client-Anwendung kennzeichnet; eine Vervielfältigungsstrategie 1710, die Regeln bereitstellt, die während der Vervielfältigung einzuhalten sind (z. B. ein Quorum der Gruppe, das zum Fortfahren mit bestimmten Aufgaben notwendig ist); eine Anforderung 1712, welche die zu vervielfältigende und auszuführende Transaktion (z. B. eine Erzeugungs- oder Aktualisierungsanforderung) kennzeichnet; und eine Anforderungsgröße 1714, welche die Größe der Anforderung kennzeichnet.

Die Vervielfältigungsanforderungsnachricht wird durch eine einzelne Client-Anwendungsinstanz (auch bekannt als der Initiator) an einen Serverprozess des DSTS-Systems gesendet. Bei Empfang der Nachricht (oder irgendwann danach) verteilt der Serverprozess die Nachricht an einen oder mehrere andere Serverprozesse der verteilten Rechnerumgebung. Insbesondere wird er in einem Beispiel an alle anderen aktuellen Serverprozesse der Verarbeitungsgruppe gesendet.

Als Antwort sendet jeder der Serverprozesse eine Vervielfältigungsrückrufnachricht an die entsprechenden Instanzen (Gleichartige) der Client-Anwendung. Ein Beispiel einer Vervielfältigungsrückrufnachricht wird mit Bezug auf Fig. 18 beschrieben. Eine Vervielfältigungsrückrufnachricht 1800 enthält zum Beispiel einen Operationscode 1802, der kennzeichnet, dass dies eine Vervielfältigungsrückrufnachricht ist; ein Feld der neuen Ressourcennamen 1804, falls irgendwelche zu erzeugen sind; eine exklusive Zugriffsgruppe 1806, die null oder mehr exklusive Ressourcen der Client-Anwendung kennzeichnet; eine gemeinsam genutzte Zugriffsgruppe 1808, die null oder mehr gemeinsam verwendete Ressourcen der Client- Anwendung kennzeichnet; eine Anforderung 1810, welche die zu vervielfältigende und auszuführende Transaktion kennzeichnet; und eine Anforderungsgröße 1812, welche die Größe der Anforderung kennzeichnet.

Zusätzlich zu Obengenanntem wird eine Vervielfältigungsrückrufergebnisnachricht von der Client- Anwendung an den DSTS-Server gesendet, nachdem die angeforderte Transaktion bearbeitet wurde. Ein Beispiel einer Vervielfältigungsrückrufergebnisnachricht wird mit Bezug auf Fig. 19 beschrieben. Eine Vervielfältigungsrückrufergebnisnachricht 1900 enthält einen Operationscode 1902, der kennzeichnet, dass dies eine Vervielfältigungsrückrufergebnisnachricht ist; ein Feld der neuen Ressourcennamen 1904, falls vorhanden, zusammen mit ihren Kennzeichen (z. B. eindeutigen Bezeichnern); einer modifizierten Ressourcengruppe 1906, einschließlich der Kennzeichen irgendwelcher modifizierter Ressourcen; und eine Gruppe gelöschter Ressourcen 1908, einschließlich der Kennzeichen irgendwelcher gelöschter Ressourcen.

Nachdem die Serverprozesse die Vervielfältigungsrückrufergebnisse empfangen, prüfen sie, ob die Transaktion abgeschlossen wurde, indem sie eine Vervielfältigungsabschlussnachricht 2000 (Fig. 20) weiterleiten. In einem Beispiel enthält eine Vervielfältigungabschlussnachricht 2000 einen Operationscode 2002, der kennzeichnet, dass dies eine Vervielfältigungsabschlussnachricht ist; und einen Operationsstatus 2004, der kennzeichnet, ob die Transaktion erfolgreich ausgeführt wurde.

Sollte das System heruntergefahren werden, verwendet das DSTS- System eine Systemabschaltnachricht, welche die Kopien der Client-Anwendung benachrichtigt, dass das System im Begriff ist, heruntergefahren zu werden. In einem Beispiel enthält eine Abschaltnachricht 2100 (Fig. 21) einen Operationscode 2102, der kennzeichnet, dass das Herunterfahren ausgeführt werden soll. Diese Nachricht hat das Ziel, den Kopien der Client-Anwendung zu gestatten, eine elegante Abschlussprozedur auszuführen, wobei irgendwelche ausstehenden Transaktionen beendet werden. Wenn die Client-Anwendungen den Systemabschaltprozess beenden, antworten sie mit einer Systemabschaltbestätigung an das DSTS-System.

Die Verwendung der oben beschriebenen Vervielfältigungsnachrichten wird unten mit Bezug auf Fig. 22a und 22b weiter beschrieben. Es wird auf Fig. 22a Bezug genommen, dort wird eine Vervielfältigungsanforderungsnachricht 2200 durch eine einzelne Client-Anwendungsinstanz 2202 an einen Serverprozess 2204 des DSTS-Systems gesendet. Der Server verteilt dann, 2206, die Vervielfältigungsanforderungsnachricht an die anderen Server 2208a, 2208b der Verarbeitungsgruppe. In diesem Beispiel sendet dann jeder der Server eine Vervielfältigungsrückrufnachricht 2210 an seine entsprechende Instanz der Client-Anwendung. Zum Beispiel sendet Server 2204 die Vervielfältigungsrückrufnachricht 2210 an die in Netzknoten 1 befindliche Client-Anwendungsinstanz. Ähnlich sendet Server 2208a eine Vervielfältigungsrückrufnachricht an die in Netzknoten 2 befindliche Client-Anwendungsinstanz usw.

Danach verarbeitet jede Kopie der Client-Anwendung 2202 (Fig. 22b) die angeforderte Transaktion, schreibt den Rückruf fest und sendet eine Vervielfältigungsrückrufergebnisnachricht 2212 an ihren entsprechenden Server. Eine Kopie der Rückrufergebnisnachricht wird dann von den Servern der Clients, die nicht Initiatoren sind (z. B. 2208a, 2208b), an den Server des Anforderungs-Initiators weitergeleitet (z. B. 2208).

Danach prüft der DSTS-Server des Anforderungs-Initiators (z. B. Server 2208), ob die Transaktion von einer Mehrheit von Kopien der Anwendung abgeschlossen wurde. Eine Mehrheit wird definiert als der ganzzahlige Quotient der Anzahl der Server durch zwei, Vernachlässigen des Dezimalteils und Addieren von eins zum Ergebnis. Zum Beispiel ist die Mehrheit von drei Client- Instanzen 3/2 + 1, d. h. 2. Wenn die Mehrheit der Client- Anwendungen beim Ausführen der Transaktion erfolgreich ist, wird die Transaktion festgeschrieben, und eine Vervielfältigungsabschlussnachricht wird von Server 2208 an seine entsprechende Anwendungsinstanz weitergeleitet. Anderenfalls wird die Transaktion abgebrochen. Der Abschluss der Transaktion durch eine Mehrheit von Kopien der Anwendung stellt die Permanenz der Operation sicher. Irgendeine Kopie der Anwendung, die nicht in der Lage ist, eine Transaktion auszuführen, wird von der DSTS-Gruppe ausgeschlossen, wie oben beschrieben.

Gemäß einem Aspekt der vorliegenden Erfindung werden die vervielfältigten verteilten Transaktionen unter Verwendung eines Zweiphasenfestschreibeprotokolls festgeschrieben. Weiterhin wird, wenn eine Transaktion durch eine Kopie des Servers festgeschrieben wird, sie auch durch die anderen Kopien der Verarbeitungsgruppe festgeschrieben.

Jede synchrone vervielfältigte Transaktion wird einer Gruppe von Zeichen (Kennzeichen) zugeordnet, für die entweder exklusiver oder gemeinsamer Zugriff während der Verarbeitung der Transaktion angefordert wird. Obwohl die Transaktionen nicht erfordern, dass vor der Einleitung irgendwelche Sperren bezüglich der Zugriffszeichen erhalten werden müssen, werden Transaktionen, die auf dieselben exklusiven Zugriffszeichen zugreifen, serialisiert. D. h., die Mitglieder einer Verarbeitungsgruppe schreiben eine Transaktion (dieselbe Transaktion) fest, ehe das Festschreiben einer anderen Transaktion gestattet wird.

Gemäß einem Aspekt der vorliegenden Erfindung wird eine Serialisierungstechnik bereitgestellt, die das parallele Einleiten von Transaktionen gestattet, die dieselben Ressourcen benutzen. Der Initiator einer Transaktion zählt auf, welche Zeichen (z. B. Kennzeichen) die Transaktion für exklusive und gemeinsam Benutzung benötigt. Als eine Alternative kann eine zentrale Zeichenzuteilungseinheit (Server) verwendet werden. Der Initiator würde Zeichen von der zentralen Zeichenzuteilungseinheit erhalten, ehe die Transaktion eingeleitet wird. Aber für eine Mehrzahl von Fällen haben die Zeichen keinen Konflikt, somit gibt es eine große Verbesserung der Leistung gegenüber einem Verfahren mit Zeichenzuteilungsserver. Falls aber Zeichen einen Konflikt haben, wird die Serialisierungstechnik der vorliegenden Erfindung ausgeführt, um die Konsistenz der Daten in jedem Mitglied der Verarbeitungsservergruppe zu erhalten.

Zum Beispiel sei angenommen, dass zwei Transaktionen gleichzeitig eingeleitet werden, die exklusiven Zugriff auf ein Zeichen mit der Bezeichnung "A" anfordern. Weiterhin sei angenommen, dass Server 1 eine Transaktion T1 einleitet und Server 2 eine Transaktion T2 einleitet. Angenommen, T1 soll A = 1 setzen und T2 soll A = 2 setzen. Weiterhin sei angenommen, dass es drei Mitglieder in der Verarbeitungsgruppe gibt, die diese Transaktionen ausführen sollen. Da die Transaktionen gleichzeitig eingeleitet werden, ist ihre Reihenfolge nicht wichtig, aber sie müssen von allen Mitgliedern in derselben Reihenfolge ausgeführt werden.

Die synchron vervielfältigten Transaktionen werden unter Verwendung eines Zweiphasenfestschreibeprotokolls ausgeführt. So werden die Daten in einer ersten Phase übertragen, Festschreibevorbereitungsphase (Prepare to Commit, PTC) genannt, und die Transaktion wird in einer zweiten Phase festgeschrieben, Festschreibephase (Commit, CMT) genannt. Die Zweiphasenfestschreibung kann parallel weitergehen (d. h., die Transaktionen T1 und T2 können parallel eingeleitet werden), wodurch die Vervielfältigung von Transaktionen leistungsfähiger wird. Aber an irgendeinem Punkt in dem Zweiphasenfestschreibeprotokoll müssen die Transaktionen serialisiert werden. Wenn nicht, treten Probleme auf, wie unten beschrieben.

Wenn der Zweiphasenfestschreibung die parallele Verarbeitung ohne Serialisierung gestattet wird, könnte das zu inkonsistenten Ergebnissen führen, wie unten dargestellt:

/ / ** der Server wartet auf Bestätigung, dass die PTCs empfangen wurden, ehe die Festschreibephase bearbeitet wird:

Das Problem hierbei ist, dass Server 1 und Server 2, die T1, T2 ausgeführt haben, in diesen Servern A = 1 setzen. Server 3 hat jedoch T2, T1 ausgeführt, und setzt als Endergebnis A = 2. Der Wert von "A" ist jetzt in der Verarbeitungsgruppe inkonsistent, und das ist in einem synchron vervielfältigten Transaktionssystem nicht akzeptabel.

Um dieses Problem zu überwinden, wird der ersten Phase des Zweiphasenfestschreibeprozesses (der PTC-Phase) gestattet, parallel zu arbeiten, und dann wird die Festschreibephase basierend auf den in der PTC gesendeten Zeicheninformationen gemäß einem Aspekt der vorliegenden Erfindung serialisiert. Das PTC-Protokoll wird so erweitert, dass es Informationen darüber liefert, welche Zeichen für exklusiven/gemeinsamen Zugriff für jede Transaktion notwendig sind. Da eine Zuordnung (A = 1) exklusiven Zugriff erfordert, wird das Zeichen "A" für exklusiven Zugriff in der PTC sowohl von T1 als auch T2 aufgezählt.

Weitere Einzelheiten bezüglich des Zweiphasenfestschreibeprotokolls werden mit Bezug auf die Fig. 23 und 24 beschrieben. Insbesondere wird ein Beispiel der ersten Phase des Zweiphasenfestschreibeprotokolls, der Festschreibevorbereitungsphase, mit Bezug auf Fig. 23 beschrieben und ein Beispiel der zweiten Phase, der Festschreibephase, wird mit Bezug auf Fig. 24 beschrieben.

Es wird auf Fig. 23 Bezug genommen, zuerst wird eine Vervielfältigungsanforderungsnachricht 2300 von der Client- Anwendungsinstanz 2302 an den Server 2304 gesendet, die kennzeichnet, dass eine PTC ausgeführt werden soll. Als Antwort auf den Empfang der PTC-Anforderung sendet Server 2304 eine PTC- Nachricht 2306 an die anderen Server der Gruppe (z. B. Server 2308a und 2308b). In einem Beispiel enthält die PTC-Nachricht dieselben Felder wie die Vervielfältigungsanforderungsnachricht sowie einen Bezeichner der Anforderung. Da Server 2304 die PTC einleitet, wird er als der Protokoll-Initiator bezeichnet.

Danach antwortet jeder Server, der nicht Initiator ist, auf die PTC-Anforderung mit einer PTC-Bestätigungsnachricht (PTC_ACK- Nachricht) 2310. Insbesondere sendet Server 2308a eine Bestätigung, die einen Operationscode sowie den Anforderungsbezeichner enthält. Ähnlich sendet Server 2308b eine Bestätigung, aber erst nach dem Serialisieren irgendwelcher Konflikte. Das heißt, in diesem Beispiel wird Server 2308b als ein Koordinator der Gruppe gewählt. So überwacht er alle PTC- Anforderungen, die er empfängt und sendet eine PTC_ACK-Nachricht 2310, die irgendwelche unverträglichen Anforderungen serialisiert. Wenn er bemerkt, dass zwei oder mehr PTCs für dieselbe exklusive Zugriffsressource (oder für eine exklusive Anforderung, die einer gemeinsam genutzten widerspricht) abgesetzt wurden, wählt der Gruppenkoordinator, eine von ihnen zuerst festzuschreiben, wartet auf die Bestätigung, dass die Aktualisierung abgeschlossen ist, schreibt dann die zweite fest und so weiter.

Der Protokoll-Initiator (z. B. Server 2304) empfängt die PTC_ACK- Nachrichten von den anderen Servern. Nachdem er alle PTC_ACK- Nachrichten für eine bestimmte Nachricht empfangen hat, sendet er eine Festschreibenachricht und leitet so die zweite Phase des Zweiphasenfestschreibeprotokolls ein.

Ein Beispiel der zweiten Phase des Zweiphasenfestschreibeprotokolls wird mit Bezug auf Fig. 24 beschrieben. Am Anfang empfängt der Protokoll-Initiator 2400 PTC_ACK-Nachrichten von allen Mitgliedern der Gruppe und sendet dann eine Festschreibenachricht 2402 an jeden der anderen Server der Verarbeitungsgruppe. Jeder Server der Gruppe sendet eine Vervielfältigungsrückrufnachricht 2404 an seine entsprechende Anwendung, um die Anwendung aufzufordern, die Operation festzuschreiben. Nach Festschreiben der Operation wird eine Vervielfältigungsrückrufergebnisnachricht 2406 von der Client- Anwendung an den DSTS-Server gesendet.

Danach wird eine Festschreibebestätigungsnachricht 2408 von jedem DSTS-Server an den Protokoll-Initiator gesendet (z. B. Server 2400). Der Protokoll-Initiator empfängt die Festschreibebestätigungsnachrichten von allen Mitgliedern der Gruppe und sendet eine Vervielfältigungsabschlussnachricht 2410 an den einleitenden Client, wenn mindestens eine Mehrheit der Mitglieder die Anforderung abgeschlossen hat.

Gemäß einem Aspekt der vorliegenden Erfindung wird diese implizite Serialisierung ohne irgendwelche weiteren Nachrichten einschließlich expliziter Sperrnachrichten der Ressourcen ermöglicht. Stattdessen leitet ein Mitglied der Verarbeitungsgruppe eine Transaktion mit der PTC-Nachricht ein. Es wartet dann auf die Bestätigung, dass die anderen Mitglieder die PTC-Nachricht empfangen haben, und diese Bestätigung wird PTC_ACK-Nachricht genannt. Wenn das einleitende Mitglied alle PTC_ACKs empfängt, kann es die Festschreibenachricht absetzen. Daher werden konkurrierende Transaktionen serialisiert, indem der Gruppenkoordinator seine Bestätigung zurückhält, wenn er in der PTC-Phase Konflikte feststellt.

Somit wurde der im vorhergehenden Beispiel geschilderte Konflikt wie folgt gelöst (angenommen Server 3 ist der Koordinator):

/ / ** Die Server warten auf die Bestätigung, dass die PTCs empfangen wurden

Während des Zweiphasenfestschreibeprozesses (und anderer Verarbeitung) einer verteilten Transaktion kann ein Fehler auftreten. Wenn ein derartiger, Fehler auftritt, stehen Prozeduren zur Wiederherstellung davon gemäß einem Aspekt der vorliegenden Erfindung zur Verfügung. In einem Beispiel wird eine transparente Wiederherstellung des DSTS-Systems ausgeführt, und es gehen während des Wiederherstellungsprozesses keine ausstehenden Transaktionen verloren. Als ein Beispiel werden die ausstehenden Transaktionen abgeschlossen, ohne das Neuschicken der Transaktionen zu erfordern, selbst wenn eine Anzahl von Mitgliedern der DSTS-Gruppe scheitert.

Gemäß einem Aspekt der vorliegenden Erfindung wird eine Möglichkeit bereitgestellt, die den Abschluss einer ausstehenden Transaktion ermöglicht, falls bei irgendeinem Mitglied der DSTS- Gruppe ein Fehler auftritt. Da das DSTS-System den Fehler einer oder mehrerer der Mitgliederkopien des Systems beheben kann, wird gesagt, das dass System eine hohe Verfügbarkeit hat. Die Lösung dieses Problems wird durch die Tatsache kompliziert, dass die Ankunft der Nachrichten in einem Zweiphasenfestschreibeprotokoll nicht synchron ist, obwohl das DSTS-System garantiert, dass Transaktionen synchron abgeschlossen werden. Das heißt, nicht alle Mitglieder empfangen die PTC- und CMT-Nachrichten gleichzeitig, und als eine Konsequenz kann zu irgendeinem Zeitpunkt jedes Mitglied eine andere Gruppe von Nachrichten bezogen auf ein Protokoll empfangen haben, und die Nachrichten können in unterschiedlicher Reihenfolge empfangen worden sein.

Es wird beispielsweise eine Momentaufnahme des DSTS betrachtet, die während der normalen Operation bei T = 4 in Fig. 25 aufgenommen wurde. An diesem Punkt hat jeder Server die folgende Gruppe von Nachrichten empfangen:

Nun sei angenommen, dass Server 2 bei T = 4 scheitert.

Im Fall eines Fehlers wird eines der verbleibenden Mitglieder als Gruppenkoordinator gewählt. In diesem Beispiel wird angenommen, dass Server 1 als Gruppenkoordinator gewählt wird. Der Gruppenkoordinator nimmt an der Wiederherstellung teil, wie hier beschrieben.

Eine Ausführungsform des mit einer Wiederherstellungsmöglichkeit verbundenen Logik wird mit Bezug auf Fig. 26 beschrieben. Zu Anfang sendet jedes verbleibende Mitglied dem Gruppenkoordinator eine Liste der Transaktionsbezeichner, für welche die PTCs seit dem letzten Synchronisationspunkt überwacht wurden, SCHRITT 2600. In diesem Beispiel sendet Server 3 PTC(C) und PTC(A). Anschließend vergleicht der Gruppenkoordinator die PTC- Bezeichner, die durch ein oder mehrere andere verbleibende Mitglieder mit ihrer eigenen Liste von PTCs gesendet wurden, SCHRITT 2602. In diesem Beispiel wird die Liste von Server 3 mit {PTC(B) und PTC(A)} verglichen.

Als Nächstes fordert der Gruppenkoordinator die tatsächliche PTC-Nachricht für irgendeine Nachricht an, die durch andere Mitglieder gemeldet, aber vom Koordinator nicht empfangen wurde, SCHRITT 2604. Zum Beispiel fordert der Gruppenkoordinator, Server 1, eine PTC(C)-Nachricht von Server 3. An diesem Punkt sind dem Gruppenkoordinator alle ausstehenden Transaktionen seit dem letzten Synchronisationspunkt bekannt. Der Gruppenkoordinator übernimmt jetzt die Rolle des Protokoll- Initiators für alle ausstehenden Protokolle. Die anderen Mitglieder der Gruppe wissen, dass die Rolle des Protokoll- Initiators geändert wurde, da das System in den Wiederherstellungsmodus geht, wenn ein Fehler auftritt.

Der Gruppenkoordinator sendet PTC-Nachrichten an alle der anderen verbleibenden Mitglieder für alle PTC-Nachrichten, die in der Gemeinschaft seiner PTC-Liste sind und der anderen PTC- Liste, die er in SCHRITT 2600 empfangen hat, SCHRITT 2606. Zum Beispiel sendet der Gruppenkoordinator {PTC(A), PTC(B), PTC(C)}. Die verbleibenden Gruppenmitglieder empfangen die ausstehenden PTCs und speichern die noch nicht empfangenen, SCHRITT 2608. Zum Beispiel speichert Server 3 PTC(B).

Anschließend senden die verbleibenden Mitglieder PTC_ACK- Nachrichten für jede der PTCs, die empfangen wurden, SCHRITT 2610. Wenn die PTC_ACKs für die Gruppenmitglieder für jede PTC empfangen wurden, sendet der Gruppenkoordinator eine Festschreibenachricht (CMT-Nachricht), SCHRITT 2612. Wenn die verbleibenden Mitglieder die Festschreibenachricht empfangen, senden sie CMT_ACK-Nachrichten, SCHRITT 2614. Wenn die CMT_ACK- Nachrichten für die ausstehenden Transaktionen empfangen wurden, hat das DSTS-System einen anderen Synchronisationspunkt erreicht (d. h. keine ausstehenden Transaktionen).

Vorteilhafterweise sind die Einzelheiten des Zweiphasenfestschreibeprozesses vor der Client-Anwendung verborgen. Insbesondere hat die Client-Anwendung keine Kenntnisse darüber, dass es andere Kopien der Anwendung gibt, die an dem Festschreibeprozeß beteiligt sind.

Weiterhin kann die oben beschriebene Wiederherstellungstechnik vorteilhafterweise mehr als einen Fehler aufnehmen. D. h., sie kann erfolgreich Transaktionen abschließen, selbst wenn Gruppenmitglieder weiterhin scheitern, und sogar, wenn die Wiederherstellung schon im Gange ist, beispielsweise so lange, wie ein Quorum der Gruppenmitglieder aufrechterhalten wird. Wenn ein Fehler bemerkt wird, wird die Technik von Anfang an neu gestartet. Eine Transaktion kann jedoch verloren gehen, wenn der Initiator der Transaktion scheitert, ehe er irgendwelche PTC- Nachrichten versenden kann, oder wenn alle einer Mehrheit von Empfängern einer PTC-Nachricht nach Empfang der Nachricht scheitern. Die Wiederherstellungstechnik ist auf alle Typen von Anwendungen anwendbar, sogar für Anwendungen, die keine Rückkehroperationen unterstützen. Weiterhin ist es ein nützliches Übertragungsprotokoll für gemeinsam benutzte nicht verteilte Systeme.

Zusätzlich zu Obengenanntem kann ein gescheitertes Mitglied wieder in die Gruppe eintreten, indem das gescheiterte Mitglied den letzten Synchronisationspunkt feststellt, der beobachtet wird, und von der aktuellen Gruppe das Delta von Transaktionen erhält, die es benötigt, um den letzten Synchronisationspunkt des DSTS-Systems zu erreichen.

In einer Ausführungsform werden Gruppenmitgliedschaft und Gruppenstatus zur Wiederherstellung des DSTS-Systems verwendet.

Oben beschrieben wurden verschiedene Aspekte der Verwaltung vervielfältigter verteilter synchroner Transaktionen.

Vorteilhafterweise werden die Details der Vervielfältigung vor den Client-Anwendungen verborgen (z. B. keine Abstimmung bei der Zweiphasenfestschreibung, keine Teilnahme an Gruppenprotokollen). Ein oder mehrere der Aspekte der vorliegenden Erfindung sind sowohl auf homogene Systeme als auch heterogene Systeme anwendbar. Als ein Beispiel werden Möglichkeiten bereitgestellt, um das Zusammenwirken der Systeme einer heterogenen Umgebung zu unterstützen.

Die vorliegende Erfindung kann in einem Herstellungsartikel enthalten sein (z. B. ein oder mehrere Computerprogrammprodukte), beispielsweise mit computernutzbarem Medium. Das Medium enthält hierin zum Beispiel ein computerlesbares Programmcodemittel zum Bereitstellen und Unterstützen der Möglichkeiten der vorliegenden Erfindung. Der Herstellungsartikel kann als ein Teil eines Computersystems enthalten sein oder getrennt verkauft werden.

Zusätzlich kann mindestens eine maschinenlesbare Programmspeichereinheit bereitgestellt werden, die deutlich mindestens ein Programm von Instruktionen verkörpert, das von der Maschine ausführbar ist, um die Möglichkeiten der vorliegenden Erfindung auszuführen.

Die hierin gezeigten Flussdiagramme sind nur Beispiele. Es kann viele Variationen zu diesen Diagrammen oder den darin beschriebenen Schritten (oder Operationen) geben, ohne vom Umfang der Erfindung abzuweichen. Zum Beispiel können die Schritte in einer anderen Reihenfolge ausgeführt werden oder es können Schritte hinzugefügt, gelöscht oder modifiziert werden. Alle diese Variationen werden als Teil der beanspruchten Erfindung betrachtet.

Obwohl hierin bevorzugte Ausführungsformen detailliert gezeigt und beschrieben wurden, wird es dem Fachmann offensichtlich sein, dass verschiedene Modifikationen, Ergänzungen, Ersetzungen und Ähnliches erfolgen können, ohne vom Wesen der Erfindung abzuweichen und diese werden daher als innerhalb des Umfangs der Erfindung betrachtet, wie in den folgenden Ansprüchen definiert.

Claims (3)

1. Verfahren zum Ausführen synchroner Vervielfältigung von Transaktionen einer verteilten Rechnerumgebung, wobei das Verfahren folgendes umfasst:
Einleiten einer Transaktion innerhalb der verteilten Rechnerumgebung durch eine Instanz einer Client-Anwendung der verteilten Rechnerumgebung; und
Vervielfältigen der Transaktion zu mindestens einer anderen Instanz der Client-Anwendung, wobei das Vorhandensein der anderen Instanz vor der Instanz, welche die Transaktion eingeleitet hat, verborgen wird.

2. System zum Ausführen synchroner Vervielfältigung von Transaktionen einer verteilten Rechnerumgebung, wobei das System folgendes umfasst:
Mittel zum Einleiten einer Transaktion innerhalb der verteilten Rechnerumgebung durch eine Instanz einer Client- Anwendung der verteilten Rechnerumgebung; und
Mittel zum Vervielfältigen der Transaktion zu mindestens einer anderen Instanz der Client-Anwendung, wobei das Vorhandensein der anderen Instanz vor der Instanz, welche die Transaktion eingeleitet hat, verborgen wird.

3. Mindestens eine Programmspeichereinheit, die durch eine Maschine lesbar ist, die mindestens ein Programm von Instruktionen deutlich verkörpert, das von der Maschine ausführbar ist, um ein Verfahren des Ausführens von synchroner Vervielfältigung von Transaktionen einer verteilten Rechnerumgebung auszuführen, wobei das Verfahren folgendes umfasst:
Einleiten einer Transaktion innerhalb der verteilten Rechnerumgebung durch eine Instanz einer Client-Anwendung der verteilten Rechnerumgebung; und
Vervielfältigen der Transaktion zu mindestens einer anderen Instanz der Client-Anwendung, wobei das Vorhandensein der anderen Instanz vor der Instanz, welche die Transaktion eingeleitet hat, verborgen wird.