DE10123067A1 - Synchrone Vervielfältigung von Transaktionen in einem verteilten System - Google Patents
Synchrone Vervielfältigung von Transaktionen in einem verteilten SystemInfo
- Publication number
- DE10123067A1 DE10123067A1 DE10123067A DE10123067A DE10123067A1 DE 10123067 A1 DE10123067 A1 DE 10123067A1 DE 10123067 A DE10123067 A DE 10123067A DE 10123067 A DE10123067 A DE 10123067A DE 10123067 A1 DE10123067 A1 DE 10123067A1
- Authority
- DE
- Germany
- Prior art keywords
- group
- transaction
- message
- client application
- distributed
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/10015—Access to distributed or replicated servers, e.g. using brokers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
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
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.
"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.
Diese Erfindung bezieht sich allgemein auf verteilte Systeme und
insbesondere auf die Verwaltung eines verteilten synchronen
Transaktionssystems.
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.
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.
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.
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.
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.
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.
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.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/583,370 | 2000-05-31 | ||
US09/583,370 US6823355B1 (en) | 2000-05-31 | 2000-05-31 | Synchronous replication of transactions in a distributed system |
Publications (2)
Publication Number | Publication Date |
---|---|
DE10123067A1 true DE10123067A1 (de) | 2002-01-03 |
DE10123067B4 DE10123067B4 (de) | 2008-04-17 |
Family
ID=24332838
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE10123067A Expired - Fee Related DE10123067B4 (de) | 2000-05-31 | 2001-05-11 | Synchrone Vervielfältigung von Transaktionen in einem verteilten System |
Country Status (2)
Country | Link |
---|---|
US (1) | US6823355B1 (de) |
DE (1) | DE10123067B4 (de) |
Families Citing this family (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7171654B2 (en) * | 2000-05-25 | 2007-01-30 | The United States Of America As Represented By The Secretary Of The Navy | System specification language for resource management architecture and corresponding programs therefore |
US7689560B2 (en) | 2000-10-13 | 2010-03-30 | Miosoft Corporation | Persistent data storage techniques |
US7587428B2 (en) * | 2000-10-13 | 2009-09-08 | Microsoft Corporation | Maintaining a relationship between two different items of data |
US20020188624A1 (en) * | 2001-04-12 | 2002-12-12 | William Landin | Active control protocol for peer-to-peer database replication |
US7120693B2 (en) * | 2001-05-08 | 2006-10-10 | International Business Machines Corporation | Method using two different programs to determine state of a network node to eliminate message response delays in system processing |
US9659292B1 (en) * | 2001-08-30 | 2017-05-23 | EMC IP Holding Company LLC | Storage-based replication of e-commerce transactions in real time |
US8738568B2 (en) | 2011-05-05 | 2014-05-27 | Oracle International Corporation | User-defined parallelization in transactional replication of in-memory database |
US7406486B1 (en) * | 2002-04-10 | 2008-07-29 | Oracle International Corporation | Transforming transactions to increase parallelism when replicating |
US7496901B2 (en) * | 2004-06-22 | 2009-02-24 | International Business Machines Corporation | Method for boundary trace with reproduction facility |
US8326764B1 (en) | 2004-09-30 | 2012-12-04 | Rockwell Automation Technologies, Inc. | Factory automation transactions |
US7461289B2 (en) * | 2006-03-16 | 2008-12-02 | Honeywell International Inc. | System and method for computer service security |
US7890457B2 (en) * | 2006-10-20 | 2011-02-15 | Oracle International Corporation | Transactionally consistent database workload replay |
US7733874B2 (en) * | 2006-10-27 | 2010-06-08 | International Business Machines Corporation | Communicating packets between devices involving the use of different communication protocols |
US7548998B2 (en) * | 2006-10-27 | 2009-06-16 | International Business Machines Corporation | Modifying host input/output (I/O) activity to allow a storage drive to which I/O activity is directed to access requested information |
US20100106744A1 (en) * | 2008-10-23 | 2010-04-29 | Microsoft Corporation | Conflict prevention for peer-to-peer replication |
US9710344B1 (en) * | 2010-12-13 | 2017-07-18 | Amazon Technologies, Inc. | Locality based quorum eligibility |
US8473775B1 (en) | 2010-12-14 | 2013-06-25 | Amazon Technologies, Inc. | Locality based quorums |
US8688729B2 (en) | 2011-08-16 | 2014-04-01 | Ca, Inc. | Efficiently collecting transaction-separated metrics in a distributed enviroment |
US9465648B2 (en) * | 2012-07-31 | 2016-10-11 | Hewlett Packard Enterprise Development Lp | Distributed transaction processing through commit messages sent to a downstream neighbor |
US8812434B2 (en) | 2012-10-12 | 2014-08-19 | Ca, Inc. | Data structure for efficiently identifying transactions |
US8856070B2 (en) * | 2012-12-21 | 2014-10-07 | International Business Machines Corporation | Consistent replication of transactional updates |
EP2973043A2 (de) | 2013-03-15 | 2016-01-20 | James Webber | Verfahren und vorrichtung zur sicherstellung konsistenter ergebnisse bei aktualisierungen auf verteilten datenbanken |
US9442971B2 (en) * | 2013-04-17 | 2016-09-13 | International Business Machines Corporation | Weighted transaction priority based dynamically upon phase of transaction completion |
US9910733B2 (en) * | 2014-06-26 | 2018-03-06 | Sybase, Inc. | Transaction completion in a synchronous replication environment |
JP6626976B2 (ja) | 2015-12-16 | 2019-12-25 | アビニシオ テクノロジー エルエルシー | 高スループット、高信頼性のデータ処理システム |
US11968250B2 (en) * | 2022-01-18 | 2024-04-23 | Dish Wireless L.L.C. | Systems and methods for a distributed data platform |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4714992A (en) | 1985-11-26 | 1987-12-22 | International Business Machines Corporation | Communication for version management in a distributed information service |
US4766566A (en) | 1986-08-18 | 1988-08-23 | International Business Machines Corp. | Performance enhancement scheme for a RISC type VLSI processor using dual execution units for parallel instruction processing |
US4766534A (en) | 1986-10-16 | 1988-08-23 | American Telephone And Telegraph Company, At&T Bell Laboratories | Parallel processing network and method |
JPH07101410B2 (ja) | 1990-01-17 | 1995-11-01 | インターナショナル、ビジネス、マシーンズ、コーポレーション | データ処理ネットワークにおいて逐次化手段の試験のため命令流の実行を同期させる方法 |
DE69130630T2 (de) | 1990-09-14 | 1999-09-09 | Hitachi Ltd | Synchrones Verfahren und Gerät für Prozessoren |
US5293619A (en) | 1991-05-30 | 1994-03-08 | Sandia Corporation | Method and apparatus for collaborative use of application program |
JP2908598B2 (ja) | 1991-06-06 | 1999-06-21 | 松下電器産業株式会社 | 情報処理装置 |
DE4497149B4 (de) * | 1993-09-24 | 2005-02-10 | Oracle Corp., Redwood City | Computerbezogenes Verfahren zur Datenreplikation in Peer-to-Peer-Umgebung |
JP2880399B2 (ja) | 1994-03-24 | 1999-04-05 | 株式会社日立製作所 | 並列計算機 |
WO1995028686A1 (en) | 1994-04-15 | 1995-10-26 | David Sarnoff Research Center, Inc. | Parallel processing computer containing a multiple instruction stream processing architecture |
US5740433A (en) * | 1995-01-24 | 1998-04-14 | Tandem Computers, Inc. | Remote duplicate database facility with improved throughput and fault tolerance |
US5774668A (en) | 1995-06-07 | 1998-06-30 | Microsoft Corporation | System for on-line service in which gateway computer uses service map which includes loading condition of servers broadcasted by application servers for load balancing |
US5828880A (en) | 1995-07-06 | 1998-10-27 | Sun Microsystems, Inc. | Pipeline system and method for multiprocessor applications in which each of a plurality of threads execute all steps of a process characterized by normal and parallel steps on a respective datum |
US5748958A (en) | 1996-04-30 | 1998-05-05 | International Business Machines Corporation | System for utilizing batch requests to present membership changes to process groups |
US5924094A (en) * | 1996-11-01 | 1999-07-13 | Current Network Technologies Corporation | Independent distributed database system |
WO1998038564A2 (en) * | 1997-02-28 | 1998-09-03 | Siebel Systems, Inc. | Partially replicated distributed database with multiple levels of remote clients |
US5941949A (en) | 1997-05-14 | 1999-08-24 | Citrix Systems, Inc. | System and method for transmitting data from a server application to more than one client node |
US6163855A (en) * | 1998-04-17 | 2000-12-19 | Microsoft Corporation | Method and system for replicated and consistent modifications in a server cluster |
US6324571B1 (en) * | 1998-09-21 | 2001-11-27 | Microsoft Corporation | Floating single master operation |
US6122630A (en) * | 1999-06-08 | 2000-09-19 | Iti, Inc. | Bidirectional database replication scheme for controlling ping-ponging |
-
2000
- 2000-05-31 US US09/583,370 patent/US6823355B1/en not_active Expired - Fee Related
-
2001
- 2001-05-11 DE DE10123067A patent/DE10123067B4/de not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
US6823355B1 (en) | 2004-11-23 |
DE10123067B4 (de) | 2008-04-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE10123067B4 (de) | Synchrone Vervielfältigung von Transaktionen in einem verteilten System | |
DE69629630T2 (de) | Struktur zur Gruppenzugehörigkeitsverwaltung in einem Mehrfachrechnersystem | |
DE60207251T2 (de) | Verfahren zur sicherstellung des betriebs eines gruppierten nachrichtenvergebenden servers während knotenausfällen und netzwerkzuteilungen | |
DE69923621T2 (de) | Verfahren und Vorrichtung zu korrekten und vollständigen Übertragungen in einem fehlertoleranten verteilten Datenbanksystem | |
DE10134492B4 (de) | Ausfallübernahme des Dateimanagementsystems in einem Rechnercluster | |
DE69811148T2 (de) | Mitgliedschaft in einem unzuverlässigen verteilten Rechnersystem | |
DE60220263T2 (de) | Server-duplexverfahren und geduplextes serversystem | |
DE69907818T2 (de) | Verfahren und Vorrichtung zur Fehlererkennung und Wiederherstellung mit vorbestimmter Replikationsart für verteilte Anwendungen in einem Netzwerk | |
DE602005002532T2 (de) | Cluster-datenbank mit ferndatenspiegelung | |
DE69822283T2 (de) | Verteilte dauerhafte Speicher für Benutzer- Anbieter- Systeme mit manchmal unterbrochenen Verbindungen | |
DE4303062C2 (de) | Verfahren zur Behebung von Systemausfällen in einem verteilten Computersystem und Vorrichtung zur Durchführung des Verfahrens | |
DE69917333T2 (de) | Übertragung einer Ressource von einem ersten Zwischenspeicher an einen zweiten Zwischenspeicher | |
DE69918467T2 (de) | Servervorrichtung und Verfahren deren Verwendung | |
DE60016371T2 (de) | Vorrichtung und verfahren um die übereinstimmung der daten in einer gruppe von einspiegelungseinrichtungen gespeichert zu behalten | |
DE102005053727B4 (de) | Verteilte Verriegelung | |
DE102008015662B4 (de) | Beseitigung von Daten | |
DE60030397T2 (de) | Belastungsverteilung in einem Netzwerk | |
DE60220418T2 (de) | Verfahren und Anbieter zur Systemsynchronisation | |
DE60018872T2 (de) | System und Methode für das Löschen von Datenbank-Aktualisierungsbilddateien nach Abschluss der dazugehörigen Transaktionen | |
DE10311082B4 (de) | Elektronikdokumentmanagementverfahren | |
DE112005002481T5 (de) | Rekonfigurierung einer redundanten Datenspeicherung | |
EP1821498B1 (de) | Ausfallsicheres System zum Verwalten von Client-Server-Kommunikation | |
DE112010004140B4 (de) | Dynamischer Austausch von Replikat-Datenträgern in einem Verbund | |
DE4420451A1 (de) | Sperrmechanismus für ein CHECK-IN/CHECK-OUT-Modell | |
DE69907852T2 (de) | Hochverfügbare asynchrone Ein/Ausgabe für gruppierte Rechnersysteme |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8320 | Willingness to grant licences declared (paragraph 23) | ||
8364 | No opposition during term of opposition | ||
8328 | Change in the person/name/address of the agent |
Representative=s name: DUSCHER, R., DIPL.-PHYS. DR.RER.NAT., PAT.-ANW., 7 |
|
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee |