-
Technisches
Gebiet
-
Die
Erfindung bezieht sich allgemein auf virtuelle Java-Maschinen und
insbesondere auf eine virtuelle Java-Maschine mit einer eingebauten
Unterstützung
für einen
fehlertoleranten Betrieb.
-
Hintergrund
der Erfindung
-
Große komplexe
Computersysteme werden durch die Integration von Softwareprogrammen
mit einer Hardware-Plattform in Gang gesetzt. Es ist wichtig, dass
derartige Systeme zuverlässig
sind, und weil viele derartige Systeme „Server" sind, wird von ihnen erwartet, dass
sie dauernd über
lange Zeitperioden ohne Ausfall oder Unterbrechung laufen. Als Ergebnis
werden verschiedene Techniken, wie z. B. die Verwendung von redundanter
Spezialzweck-Hardware, verwendet, um einen kontinuierlichen Betrieb
sicherzustellen. Derartige Techniken stellen etwas bereit, was allgemein
als „Fehlertoleranz" bezeichnet wird,
weil sie es ermöglichen,
dass derartige Systeme einen Fehler, wie z. B. den Ausfall einer
Hardware-Komponente verdecken, das heißt sich hiervon erholen.
-
Eine
Fehlertoleranz kann weiterhin durch eine Software-Technologie erreicht
werden, die handelsübliche
Hardware verwendet, die weniger aufwändig ist. In vielen Fällen verwenden
derartige Techniken „Prüfpunkte", bei denen der Systemstatus von
einer Instanz einer Anwendung zu einer Reserveinstanz kopiert wird,
derart, dass die Reserveinstanz die Verarbeitung unter Verwendung
des kopierten Systemstatus als Ausgangspunkt übernehmen kann.
-
Ein
Telekommunikationsnetzwerk ist ein Beispiel eines komplizierten
Systems, das zuverlässig sein
muss. Telekommunikationsnetzwerke erleichtern die Kommunikationen
zwischen einer großen Anzahl
von öffentlichen
und privaten Kommunikationssystemen, indem sie vielfältige Funktionen,
wie z. B. die Vermittlung, die Abrechnung, die Zeitverwaltung und
dergleichen, bereitstellen. Ein Telekommunikationsnetzwerk stellt
derartige Funktionen über Netzwerk-Schaltvermittlungen
oder Knoten bereit, die über
Verbindungsstrecken oder Kanäle
eines Übertragungsmediums
miteinander verbunden sind, wie z. B. Draht, Lichtleitfaserkabel
oder Funkwellen. Einige der Knoten sind mit einem oder mehreren
Benutzern verbunden.
-
Moderne
Telekommunikationsnetzwerke erfordern eine komplexe automatisierte
Vermittlung und zu diesem Zweck sind Softwareprogramme so geschrieben,
dass sie eine zuverlässige
verlässliche Betriebsleistung
und eine effiziente Nutzung von Ressourcen sowie Dienstmerkmale
und Funktionen ergeben, wie z. B. Anklopfen, Anrufer-Identifikation und
dergleichen. Derartige Systeme können
in einer Anzahl von unterschiedlichen Arten in Abhängigkeit davon
konfiguriert sein, welche Arten von Übertragungsmedien verwendet
werden, welche Arten von Benutzer mit Diensten versorgt werden,
und welche Mischung von Merkmalen gekauft wird. Als Ergebnis derartiger
Kompliziertheiten und der großen
Anzahl von unterschiedlichen Konfigurationen ist es schwierig, derartige
Systeme in zuverlässiger
und verlässlicher
Weise zu betreiben. Softwareprogramme, die derartige Systeme betreiben,
müssen
daher extrem zuverlässig
sein und eine sehr hohe Fehlertoleranz erzielen.
-
Eine
Programmiersprache, die zur Ausgestaltung von Software für derartige
Systeme geeignet ist, ist „Java", die von der Firma
Sun Microsystems, Inc., Palo Alto, Kalifornien eingeführt wurde.
Java wurde als eine objektorientierte, verteilte, interpretierte,
robuste, sichere, übertragbare,
Architektur-neutrale Multipfad- und dynamische Computersprache beschrieben.
-
Um
eine Fehlertoleranz für
Softwaresysteme unter Verwendung von Java zu erzielen, kann Anwendungssoftware
derart geschrieben werden, dass die gesamten Fehlertoleranz-Fähigkeiten,
unter Einschluss der Ableitung von Prüfpunkten, von dem Entwickler
in das Anwendungsprogramm eingebaut werden. Die Erfahrung hat jedoch
gezeigt, dass dies gegebenenfalls keine optimale Lösung ist.
In vielen Fällen
erfolgen Änderungen
der Anwendungsprogramme ohne korrektes Ändern der Teile des Programms, die
die Prüfpunktbildung
beeinflussen, so dass die Prüfpunkte
nicht genau sind und der in die Sicherungskopie kopierte Systemzustand
verfälscht
ist. Zusätzlich
können
in Anwendungssoftware entwickelte Mechanismen auch auf den Software-Quellcode
einwirken (weil zusätzlicher
Code in einer Weise hinzugefügt
wird, die das Verständnis
der Betriebsweise des Systems unter normalen Bedingungen verworren
macht), oder es können
zusätzliche Ineffizienzen
in das Softwareprogramm eingeführt werden.
Entsprechend wurde fortgesetzt nach der Entwicklung von Verfahren
für Mechanismen
innerhalb der virtuellen Java-Maschine (JVM) gesucht, die es der
JVM ermöglichen,
die Prüfpunktbildung
in einer Weise zu unterstützen,
die weniger störend
ist, effizienter ist und mit größerer Wahrscheinlichkeit
genaue Prüfpunktdaten
berechnet.
-
Eine
Veröffentlichung
mit dem Titel „On
Patterns for Practical Fault Tolerant Software in Java" von Golden Richard,
Shengru Tu (XP 010319078) und eine weitere Veröffentlichung mit dem Titel „Primary-Backup
Object Replications in Java" von
Li Wang, Wanlei Zhou (XP 010302263) diskutieren beide Datenrettungs-verfahren
unter Verwendung von Prüfpunkten
in Java-basierten Systemen. Die
EP 0449660 (Toshiba)
beschreibt eine Schattenverarbeitung zur Nachbildung des Zustandes
eines Prozesses im Fehlerfall.
-
Zusammenfassung
der Erfindung
-
Gemäß der vorliegenden
Erfindung wird ein Verfahren zur zuverlässigen und effizienten Unterstützung von
fehlertoleranten Mechanismen in einer virtuellen Java-Maschine (JVM) durch
Modifizieren der JVM als solcher offenbart. Derartige Modifikationen
an einer ersten JVM ermöglichen
es in vorteilhafter Weise, dass die erste JVM interne Informationen, die
von der ersten JVM unterhalten werden, verwendet, um Prüfpunkte
für Objekt
zu bilden, die während des
Prozesses des Antwortens auf ein Ereignis einer Transaktion erzeugt,
modifiziert und/oder gelöscht/verworfen
werden. Die Objekte, für
die der Prüfpunkt
gebildet wurde, werden zu einer zweiten JVM gesandt und in dieser
gespeichert, derart, dass die zweite JVM die Verantwortlichkeiten
der ersten JVM übernehmen
kann, wenn die erste JVM ausfällt. Der
Programmierer auf der Anwendungsebene wird somit in vorteilhafter Weise
von der Last der Einfügung
von Prüfpunkten
in den Source-Code und/oder den Objekt-Code eines Anwendungsprogramms
entlastet.
-
Gemäß einem
ersten Gesichtspunkt der vorliegenden Erfindung wird ein Verfahren
geschaffen, das Mechanismen zur Unterstützung eines fehlertoleranten
Betriebs für
eine erste virtuelle Java-Maschine („JVM") bereitstellt, mit den folgenden Schritten:
- (a) Modifizieren der ersten JVM zur Verwendung von
Informationen, die von der ersten JVM unterhalten werden, um Objekte
zu identifizieren, die während
des Prozesses eines Reagierens auf ein Ereignis einer Transaktion
geschaffen, modifiziert und/oder verworfen werden, wobei diese Objekte zumindest
einen Teil eines Prüfpunktes
definieren;
- (b) Liefern des zumindest einen Teils eines Prüfpunktes
an zumindest eine zweite JVM; und
- (c) Speichern des zumindest einen Teils eines Prüfpunktes
in der zumindest einen zweiten JVM zur Verwendung durch die zumindest
eine zweite JVM bei der Verarbeitung nachfolgender Ereignisse der
Transaktion.
-
Bei
einer bevorzugten Ausführungsform
ist die erste JVM mit einer Schreibsperre versehen, wobei der Schritt
des Modifizierens weiterhin die Verwendung der Schreibsperre zur
Verfolgung von Objekten umfasst, die während eines Prozesses einer Reaktion
auf ein Ereignis einer Transaktion geschaffen, modifiziert und/oder
verworfen werden.
-
Kurze Beschreibung
der Zeichnungen
-
Zum
vollständigeren
Verständnis
der vorliegenden Erfindung und deren Vorteile wird nunmehr auf die
folgende Beschreibung unter Bezugnahme auf die beigefügten Zeichnungen
verwiesen, in denen:
-
1 eine
schematische Darstellung ist, die eine Anordnung von virtuellen
Java-Maschinen („JVM's") zeigt, die mit einem Netzwerk verbunden sind;
-
2 ein
Ablaufdiagramm ist, das Schritte zur Realisierung einer bevorzugten
Ausführungsform der
vorliegenden Erfindung zeigt; und
-
3–18 eine
Reihe von schematischen Darstellungen sind, die die Schaffung, Modifikation,
das Löschen
und die Bewegung von Objekten während
der Verarbeitung von Ereignissen zeigen, die eine Netzwerk-Transaktion
gemäß verschiedener Ausführungsformen
der vorliegenden Erfindung umfasst.
-
Ausführliche
Beschreibung
-
In 1 der
Zeichnungen bezeichnet die Bezugsziffer 10 allgemein ein
System, das ein Netzwerk 20 umfasst, das mit einer ersten
virtuellen Java-Maschine („JVM") 30 und
einer zweiten JVM 40 verbunden ist, die Merkmale der vorliegenden
Erfindung verwirklichen. Das Netzwerk 20 kann beispielsweise ein
Telekommunikationsnetzwerk, wie z. B. ein öffentliches landgestützes Mobilfunk-Netzwerk
(PLMN) (nicht gezeigt) umfassen, das beispielsweise ein übliches
Telefon, eine private Nebenstellenvermittlung (PBX), ein Zugangs-Durchgangsamt,
ein Modem eines persönlichen
Computers (PC), einen Zugang an das Internet oder dergleichen umfassen
kann.
-
Die
JVM's 30 und 40 können auf
der gleichen oder unterschiedlichen (nicht gezeigten) Computerplattformen
realisiert werden, wobei diese Plattformen aus irgendeiner einer
Anzahl von unterschiedlichen Computerplattformen ausgewählt werden
können,
wie z. B. ein persönlicher
Computer („PC"), ein Macintosh-Computer,
eine Unix-Arbeitsstation oder dergleichen, auf denen irgendein eine
Anzahl von unterschiedlichen Betriebssystemen läuft, wie z. B. Unix, Linux,
Windows, MacOS oder dergleichen. Derartige Computerplattformen und
Betriebssysteme werden als gut bekannt betrachtet und werden daher nicht
mit weiteren Einzelheiten beschrieben.
-
Wie
dies weiter unten beschrieben wird, schließen die JVM's 30 und 40 einen
Stapelspeicher 32 bzw. 42, eine Prüfpunkt-Umgebungsfunktion 34 bzw. 44 und
eine Datenabfall-Sammelfunktion 36 bzw. 46 ein.
-
Die
Stapelspeicher 32 und 42 sind in einen Teil 32a bzw.
einem Teil 42a zur Speicherung eines geeigneten Anwendungsprogramms
unterteilt, das zur Verarbeitung von Transaktionen wirksam ist,
die von dem Netzwerk 20 an die JVM's 30 und 40 übertragen
werden. Es ist nicht erforderlich, dass ein derartiges Anwendungsprogramm
irgendeine Funktion einschließt,
die für
eine Prüfpunktbildung
konfiguriert ist, wie dies weiter unten beschrieben wird.
-
Die
Datenabfall-Sammelfunktionen 36 und 46 sind für die Verwaltung
des Stapelspeichers und zum Freimachen von Stapelspeicher verantwortlich, der
von Datenobjekten belegt ist, die nicht mehr von der laufenden Anwendung
verwendet werden. Irgendeine Anzahl von unterschiedlichen Arten
von Datenabfall-Sammelfunktionen
ist verfügbar
und kann zur Verwendung in den JVM's 30 und 40 realisiert
werden; beispielsweise können
Generationskopien erzeugende Datenabfall-Sammelfunktionen verwendet werden, die „aktive" Objekte (beispielsweise Wurzelobjekte
und Objekte, auf die von einem anderen Objekt verwiesen oder auf
dieses gezeigt wird) von einem „neuen" Teil des Speichers zu einem „alten" Teil des Speichers
befördern.
Aus Gründen
der Erläuterung,
und weil dies bevorzugt wird, wird die vorliegende Erfindung unter
Verwendung einer derartigen Generationskopien erzeugenden Datenabfall-Sammelfunktion
beschrieben. Zu diesem Zweck sind die Stapelspeicher 32 und 42 weiterhin
in „NEU"-Speicher 32b bzw. 42b und „ALT"-Speicher 32c bzw. 42c zur
Verwendung durch die jeweiligen Datenabfall-Sammelfunktionen 36 und 46 unterteilt.
-
Derartige
Generationskopien erzeugende Datenabfall-Sammelfunktionen 36 und 46 verwenden
vorzugsweise eine (nicht gezeigte) „Schreibsperre", die in der Technik
gut bekannt ist, und mit der alle Änderungen von Daten in den
Stapelspeichern, die von der jeweiligen Datenabfall-Sammelfunktion
verwaltet werden, nachverfolgt werden. Wenn dies möglich ist,
verwendet die vorliegende Erfindung die Schreibsperre der Datenabfall-Sammelfunktionen 36 und 46 erneut,
um auf diese Weise die Effizienz des Systems 10 zu verbessern.
Alternativ können
die JVM's 30 und 40 eine
Datenabfall-Sammelfunktion verwenden, die keine Schreibsperre vorsieht,
und eine Schreibsperre kann in einer gut bekannten Weise zu der
nachfolgend beschriebenen Prüfpunkt-Bildungsfunktion
hinzugefügt
werden.
-
Das
Software-Anwendungsprogramm, das sich in den Speichern 32a und 42a befindet,
verwendet vorzugsweise ereignisgesteuerte Modelle mit einem „Ablauf
bis zur Ausführung"-Modell der Verarbeitung,
wobei, sobald ein Ereignis empfangen wird, es bis zum Abschluss
verarbeitet wird, ohne dass sich eine Unterbrechung durch andere
Pfade oder Prozesse in der JVM ergibt, und eine Antwort wird in passender
Weise erzeugt. Der Punkt des Empfangs eines derartigen Ereignisses
und der Punkt des Abschlusses der Verarbeitung eines derartigen
Ereignisses definieren zwei Zeitpunkte, wobei zwischen diesen Zeitpunkten
das Anwendungsprogramm Datenobjekte, die in den Stapelspeichern 32 und 42 gespeichert
sind, hinzufügt,
modifiziert und/oder verwirft, und auf diese Weise den Zustand des
Programms ändert.
Gemäß der vorliegenden
Erfindung werden derartige hinzugefügte, modifizierte und verworfene
Datenobjekte durch die Schreibsperre der Datenabfall-Sammelfunktion verfolgt,
wie dies weiter unten erläutert
wird. Die Sammlung einer Kopie der Datenobjekte, die während eines
Ereignisses hinzugefügt,
modifiziert und verworfen werden, stellt die Änderung des Zustandes des Programms
dar, und wird hier als ein Prüfpunkt
bezeichnet. Der Prüfpunkt, wie
er hier verwendet wird, stellt damit den Unterschied dar, der während der
Ausführung
eines Software-Anwendungsprogramms
zwischen zwei Zeitpunkten hinsichtlich des Zustandes dieses Programms
auftritt, wobei dieser Zustand durch die Datenobjekte in dem Stapelspeicher 32 und 42 der
jeweiligen JVM's 30 und 40 dargestellt
ist. Der Prüfpunkt
kann somit zur Aktualisierung des Zustandes des Programms in einer
anderen JVM verwendet werden. Weil das Anwendungsprogramm hier so
betrachtet wird, als ob es jedes Ereignis bis zum Abschluss ablaufen
lässt,
wird der Zustand des Anwendungsprogramms, der erforderlich ist,
um das nächste
Ereignis zu verarbeiten, von Objekten auf dem Stapel erfasst, so
dass es nicht erforderlich ist, den Prozessor-Stapel, die Maschinenregister und dergleichen
zu dem Prüfpunkt
zu kopieren.
-
Um
die Erzeugung des Prüfpunktes
zu erleichtern, ist die Prüfpunkt-Umgebung 34 in
drei Speicherteile aufgeteilt, nämlich
einen „HINZUFÜGEN"-Teil 34a,
einen „MODIFIZIEREN"-Teil 34b und einen „VERWERFEN"-Teil 34c.
In ähnlicher
Weise ist die Prüfpunkt-Umgebung 44 in
drei Speicherteile aufgeteilt, nämlich
einen „HINZUFÜGEN"-Teil 44a,
einen „MODIFIZIEREN"-Teil 44b und
einen „VERWERFEN"-Teil 44c.
Obwohl sie nicht als solche gezeigt sind, können die Speicherteile der
Prüfpunkt-Umgebungen 34 und 44 in
die Stapelspeicher 32 und 42 innerhalb der jeweiligen
JVM's 30 und 40 integriert
werden, und sie können
verschiedene in der Technik gut bekannte Datenstrukturen verwenden,
um Sammlungen von Objekten in jedem Teil nachzuverfolgen. Aus Gründen der
Erläuterung
wird hier angenommen, dass eine getrennte Prüfpunkt-Umgebung 34 und 44 für jede Transaktion existiert,
obwohl dies nicht erforderlich ist. Weiterhin zeigt zu Erläuterungszwecken
das nachfolgend erläuterte
Beispiel keine verschachtelte Verarbeitung von Ereignissen für mehrfache
Transaktionen, obwohl dies normalerweise der Fall sein würde; statt dessen
wird, wie dies hier gezeigt, eine Transaktion verarbeitet, bevor
das System 10 eine neue Transaktion annimmt.
-
Obwohl
dies nicht gezeigt ist, schließen
die JVM's 30 und 40 außerdem eine
System-Schnittstelle,
eine Ausführungsmaschine
(zur Ausführung
von Befehlen, die in Verfahren von geladenen Klassen enthalten sind),
Pfade und dergleichen. Weiterhin schließen die JVM's 30 und 40 eine Einrichtung
ein, die eine Kenntnis der internen Struktur aller Datenobjekte
des Anwendungsprogramms in dem Speicher 32a und 42a aufrechterhält und führt. Diese
Einrichtungen sind durch die Architektur der jeweiligen JVM entsprechend
gut bekannter Spezifikationen definiert, denen eine JVM gehorchen
muss, um Java-Software ablaufen zu lassen.
-
Gemäß der vorliegenden
Erfindung wird die die JVM's 30 und 40 definierende
Software modifiziert, um viele Merkmale zu verwenden, die üblicherweise
durch die jeweiligen JVM's
bereitgestellt werden, um die JVM's mit der Fähigkeit zu versehen, Transaktionen
mit Prüfpunkten
zu versehen. Zu diesem Zweck ist 2 ein Ablaufdiagramm,
das Schritte zeigt, die von den JVM's 30 und 40 realisiert
werden, unter Modifikation gemäß der vorliegenden
Erfindung für
die Prüfpunkt-Bildung.
Aus Gründen
der Exaktheit wird die Betriebsweise der vorliegenden Erfindung
unter Verwendung einer Transaktion „T" von einem Beispiel verdeutlicht, die
drei Ereignisse (das heißt
Mitteilungen) umfasst, wie z. B. ein einfacher Telefonanruf mit
einem „Handapparat-Abhebe-Ereignis", einer „Antwort-Mitteilung" und einem „Einhängen", wobei es verständlich ist,
dass eine Transaktion mehr oder weniger als drei Ereignisse umfassen
kann. Für
die Zwecke der Erläuterung
werden die Zwischenverbindungen zwischen dem Netzwerk 20 und
den JVM's 30 und 40 nachfolgend
nicht mehr gezeigt, sofern nicht eine Mitteilung zwischen diesen
Teilen ausgetauscht wird.
-
Gemäß 2 beginnt
im Schritt 202 die Ausführung
und sie geht zum Schritt 204 über, in dem übliche Protokolle
verwendet werden, um festzustellen, welche der JVM's 30 und 40 das
nächste
Ereignis einer Transaktion verarbeitet, das von dem Netzwerk 20 empfangen
wird. Eine derartige Feststellung kann beispielsweise auf der Verfügbarkeit
einer JVM beruhen, oder sie kann so durchgeführt werden, dass die Verwendung
einer JVM vermieden wird, die unzuverlässig ist oder die ausgefallen
ist. Techniken zur Durchführung
einer derartigen Feststellung, wie z. B. das „Prozessgruppen"-Modell sind in der
Technik gut bekannt und werden hier nicht ausführlich erläutert. Bei dem vorliegenden
Beispiel wird angenommen, dass zu Anfang die erste JVM 30 die
nächste
Transaktion verarbeitet, und sie wird somit als primäre JVM bezeichnet,
während
die zweite JVM 40 als eine Reserve-JVM bezeichnet wird.
-
Im
Schritt 206 warten die JVM's 30 und 40 auf den
Empfang eines ersten Ereignisses einer nächsten Transaktion von dem
Netzwerk 20. Bei der Übertragung
eines ersten Ereignisses einer nächsten Transaktion
von dem Netzwerk 20, wie dies in 3 gezeigt
ist, empfangen beide JVM's 30 und 40 das Ereignis
und speichern es in den jeweiligen Stapelspeichern 32 und 42.
-
Im
Schnitt 208 wird eine Feststellung durch die erste JVM 30 getroffen,
ob das im Schritt 206 empfangene Ereignis das erste Ereignis
einer neuen Netzwerk-Transaktion
T ist. Wenn festgestellt wird, dass das empfangene Ereignis ein
erstes Ereignis einer neuen Transaktion T ist, so geht die Ausführung zum
Schritt 210 über,
anderenfalls geht die Ausführung
zum Schritt 212 über.
Im Schritt 210 wird in den NEU-Speichern 32b und 42b Platz
zum Speichern von Objekten zugeteilt, die erzeugt werden, während Ereignisse
der Transaktion T verarbeitet werden, wie dies weiter unten erläutert wird.
Nach der Zuteilung der NEU-Speicher 32b und 42b im
Schritt 208 geht die Ausführung zum Schritt 212 über.
-
Im
Schritt 212 beginnt die Schreibsperre mit der Verfolgung
der Schaffung, Modifikation und des Löschens von Datenobjekten, die
der Transaktion T zugeordnet sind, während das derzeitige Ereignis verarbeitet
wird, um auf diese Weise kontinuierlich die Prüfpunkt-Umgebung 34 zu
aktualisieren. Alle neuen Objekte werden zu dem HINZUFÜGEN-Teil 34a hinzugefügt, alle
modifizierten Objekte werden zu dem MODIFIZIEREN Teil 34b hinzugefügt, und die
Identität
aller gelöschten
Objekte wird in dem VERWERFEN-Teil 34c aufgezeichnet.
-
Im
Schritt 214 wird das derzeitige Ereignis als das erste
Ereignis in der Folge des vorliegenden Beispiels in einer gut bekannten
Weise durch ein geeignetes Anwendungsprogramm verarbeitet, das in dem
Speicher-Teil 32a der JVM 30 gespeichert ist. Die
Verarbeitung des Ereignisses im Schritt 214 läuft vorzugsweise
bis zum Abschluss ab. Während
das Ereignis auf diese Weise verarbeitet wird, werden Datenobjekte,
für die
als Beispiel hier die Objekte 1, 2 und 3 angegeben
sind, für
die Transaktion T geschaffen, wie dies in 4 gezeigt
ist, wobei das Objekt 1 auf das Objekt 2 „zeigt" und das Objekt 2 auf das
Objekt 3 „zeigt". Die Schaffung von
Datenobjekten und Zeigern zwischen Datenobjekten wird als in der
Technik gut bekannt betrachtet und wird daher hier nicht näher erläutert. Auf
das Objekt 1 selbst kann durch Daten gezeigt werden, die
in dem Stapel- oder Registersatz des Prozessors unterhalten werden,
so dass ein Datenabfall-Sammel-Algorithmus es als ein „aktives" Objekt lokalisieren
kann. Im Schritt 216 wird nach Abschluss der Verarbeitung
des ersten Ereignisses im Schritt 214 eine passende Antwort
erzeugt und an das Netzwerk 20 ausgesandt, wie dies in 5 gezeigt
ist.
-
Im
Schritt 218 führt
die JVM 30 eine Feststellung durch, ob das derzeitige Ereignis
das letzte Ereignis der Transaktion T ist, die verarbeitet wird. Wenn
festgestellt wird, dass das derzeitige Ereignis nicht das letzte
Ereignis ist, geht die Ausführung
zum Schritt 204 über;
anderenfalls geht die Ausführung zum
Schritt 220 über.
Im Schritt 220 ist die Verarbeitung der Transaktion T abgeschlossen,
und alle der Transaktion T zugeordneten Datenobjekte werden aus
beiden JVM's 30 und 40 verworfen
oder gelöscht,
und die Ausführung
kehrt zum Schritt 204 zurück. Für das vorliegende Beispiel
stellt das zuletzt verarbeitete Ereignis (das heißt das erste
Ereignis) nicht das letzte Ereignis der Transaktion T dar, und die
Ausführung
geht von dem Schritt 218 auf den Schritt 222 über.
-
Im
Schritt 222 wird die Datenabfall-Sammelfunktion 36 ausgeführt, um
irgendwelche „toten" Objekte (das heißt Objekte,
auf die nicht durch ein anderes Objekt gezeigt wird) von dem NEU-Speicher 32b zu
entfernen, bevor der Prüfpunkt
berechnet wird. Dieser Schritt 222 vermeidet den Fall,
bei dem Objekte, die nicht länger
Teil des Zustandes der Transaktion sind, zu der Reserve-JVM kopiert
werden, so dass die Gesamteffizienz des Prüfpunkt-Prozesses verbessert
wird. Entsprechend werden die Datenobjekte 1, 2 und 3 von
dem NEU-Speicher 32b zu dem ALT-Speicher 32c gemäß 6 „befördert" (das heißt bewegt).
Die hier zu Erläuterungszwecken
gezeigte Verwendung einer Generationskopie-Datenabfall-Sammelfunktion
schließt
nicht die Verwendung anderer Techniken aus. Die Verwendung einer
derartigen Sammeleinrichtung mit Sammlungen, die an den Zyklus der
Ereignisverarbeitung gebunden sind, kann jedoch sowohl die Effizienz
dieses Sammelns als auch die der Prüfpunkt-Bildungsfunktion verbessern,
die in dieser Erfindung beschrieben wird. Die Datenabfall-Sammlung
wird als in der Technik gut bekannt betrachtet und wird daher hier
nicht mit weiteren Einzelheiten beschrieben. Im Schritt 224 wird
der Inhalt des Prüfpunktes
berechnet, und die Schreibsperre unterbricht die Verfolgung von Änderungen
an dem Stapelraum (für
die Zwecke der Prüfpunkt-Bildung).
Die Berechnung des Prüfpunktes
verwendet die Daten in den HINZUFÜGEN- (34a), MODIFIZIEREN-
(34b) und VERWERFEN- (34c) Teilen der Prüfpunktumgebung 34,
um Änderungen
an dem Programmzustand zu identifizieren, so dass, wie dies weiter
unten erläutert
wird, Objekte in den HINZUFÜGEN-
und MODIFIZIEREN-Teilen zur Reserve-JVM 40 kopiert werden
können,
während
in dem VERWERFEN-Teil identifizierte Objekte von der Reserve-JVM 40 entfernt
werden können. 7 zeigt
den Zustand der Prüfpunkt-Umgebung
im Schritt 224 nach der Verarbeitung des ersten Ereignisses.
-
Im
Schritt 226 werden die in der Prüfpunkt-Berechnung des Schrittes 224 identifizierten Objekte „rangiert". Entsprechend wird
jedes identifizierte Objekt codiert, um sicherzustellen, dass es
erfolgreich von einer JVM zur anderen übertragen werden kann, selbst
wenn die JVM's auf
heterogenen Computerplattformen laufen.
-
Irgendeine
geeignete Codiertechnik, wie z. B. die Serialisierung, die derzeit
in Java für
das Aufrufen entfernter Verfahren (RMI) verwendet wird, kann zur
Codierung der identifizierten Objekte verwendet werden. In dem Prozess
der Codierung werden Zeiger zwischen Objekten in Objekt-Identifikationen
oder „Etiketten" umgewandelt, die
nicht von Maschinenadressen (das heißt Adressen zu den Speicherräumen in
einer bestimmten Maschine) abhängig
sind, so dass eine die Objekte empfangende JVM die Zeiger-basierten
Zuordnungen zwischen Objekten neu schaffen kann. Techniken zur Codierung
von Objekten und zur Darstellung von Zeigern sind in der Technik
gut bekannt und werden hier nicht weiter erläutert. Objekte werden vorzugsweise
innerhalb der JVM 30 unter Verwendung der internen Kenntnis
der JVM über
Objekt-Strukturen
und die Effizienz seines internen Software-Codes rangiert. Der Prüfpunkt wird aus
den codierten zu kopierenden Objekten (von den HINZUFÜGEN- und
MODIFIZIEREN-Speicherteilen 34a und 34b) und den
Datensätzen,
die zu verwerfende Objekte (aus dem Speicherteil 34e) identifizieren,
zusammen mit irgendwelchen Verwaltungsdaten gebildet, die erforderlich
sind, um den zumindest einen Teil eines Prüfpunktes zu verwalten.
-
Im
Schritt 228 wird der im Schritt 224 erzeugte Prüfpunkt,
der alle Objekte, die in den HINZUFÜGEN- und MODIFIZIEREN-Speicherteilen 34a und 34b gespeichert
und in dem VERWERFEN-Speicherteil 34c der Prüfpunkt-Umgebung 34 identifiziert sind,
den jeweiligen Speicherteilen 44a, 44b und 44c der
Prüfpunkt-Umgebung 44 der
zweiten JVM zur Speicherung und Aufzeichnung in diesem zugeführt, wie
dies in 8 gezeigt ist. Verschiedene
in der Technik gut bekannte Kommunikationsprotokolle stehen zur
Zustellung der Prüfpunkt-Mitteilung
zur Verfügung.
Die HINZUFÜGEN-
(34a), MODIFIZIEREN- (34b) und VERWERFEN- (34c) Teile
der Prüfpunkt-Umgebung 34 werden
Daten befreit, die dem derzeitigen (das heißt dem ersten) Ereignis der Transaktion
zugeordnet sind.
-
Im
Schritt 230 wird der in der Prüfpunkt-Umgebung 44 gespeicherte
Prüfpunkt
zu dem ALT-Speicher 42c der zweiten JVM 40 bewegt,
wie dies in 9 gezeigt ist. Zusätzlich werden
die Zeiger modifiziert, so dass Etiketten, die Objekte identifizieren, auf
die gezeigt wird, durch Positionsadressen in dem ALT-Speicher 42c ersetzt
werden, so dass von der ersten JVM verwendete Zeiger in richtiger
Weise so umgewandelt werden, dass sie auf die gleichen Objekte in
der zweiten JVM 40 zeigen.
-
Die
Ausführung
der vorstehenden Schritte 228 und 230 erfolgt
unmittelbar nach dem Schritt 226, so dass der Transaktions-Status
des Speichers in den JVM's 30 und 40 zu
allen Zeiten praktisch identisch ist. Bei Abschluss des Schrittes 230 kehrt die
Ausführung
zum Schritt 204 zurück.
-
Es
ist zu erkennen, dass der Zustand der Transaktion T in den ALT-Speichern 32c und 42c der JVM's 30 und 40 gemäß 9 praktisch
identisch ist. Daher kann irgendeine der JVM's 30 und 40 das nächste Ereignis
der Transaktion verarbeiten. Dies ist besonders vorteilhaft, wenn
die JVM 30 ausfallen würde
oder auf andere Weise nicht mehr verfügbar sein würde, um das nächste Ereignis
der Transaktion T zu verarbeiten, das von dem Netzwerk 20 übertragen
wird.
-
In
dem Fall, in dem die erste JVM 30 ausfällt, bevor sie vollständig das
erste Ereignis verarbeitet hat und einen Ausgang und einen Prüfpunkt erzeugt hat,
so muss dieses Ereignis von der Reserve-JVM 40 verarbeitet
werden. Die Koordinationsfunktion, die vorstehend in dem Schritt 204 beschrieben
wurde, und die beispielsweise das „Prozessgruppen"-Modell der Software-Fehlertoleranz
verwendet, ist für
die Abwicklung eines derartigen Ausfalls verantwortlich. Wenn (wie
dies in dem vorliegenden Beispiel gezeigt wurde) das Ereignis das
erste Ereignis der Transaktion ist, so wird die Reserve-JVM 40 effektiv
zur primären
JVM und verarbeitet die Transaktion, als ob einer der vorstehend
beschriebenen Schritte erfolgt wäre.
-
Im
Schritt 204 warten die JVM's 30 und 40 auf das
nächste
Ereignis der Transaktion T von dem Netzwerk 20. Bei Empfang
des nächsten
Ereignisses, das heißt
des zweiten Ereignisses in der Folge des vorliegenden Beispiels,
werden übliche
Protokolle ausgeführt,
um festzustellen, welche der JVM's 30 und 40 das
nächste
Ereignis der Transaktion T verarbeiten wird, das von dem Netzwerk 20 empfangen wird.
In dem vorliegenden Beispiel wird angenommen, dass die JVM 30 nicht
ausgefallen ist und zur Verfügung
steht und daher die Transaktion T weiter verarbeitet. Daher wird
die JVM 30 für
die Verarbeitung des nächsten
Ereignisses der Transaktion T bestimmt und bleibt weiter die primäre JVM,
während die
zweite JVM 40 weiterhin als Reserve-JVM wirkt.
-
Im
Schritt 206 warten die JVM's 30 und 40 auf den
Empfang des zweiten Ereignisses der Transaktion T von dem Netzwerk 20.
Bei der Übertragung des
zweiten Ereignisses der Transaktion T von dem Netzwerk 20,
wie dies in 10 gezeigt ist, empfangen beide
JVM's 30 und 40 das
Ereignis und zeichnen es in den jeweiligen Stapelspeichern 32 und 42 auf.
-
Im
Schritt 208 erfolgt eine Feststellung durch die erste JVM 30,
ob das im Schritt 206 empfangene Ereignis das erste Ereignis
einer neuen Netzwerk-Transaktion T ist. Weil im vorliegenden Beispiel das
derzeitige Ereignis ein zweites Ereignis und nicht ein erstes Ereignis
ist, geht die Ausführung
zum Schritt 212 über.
Im Schritt 212 beginnt die Schreibsperre der ersten JVM 30 mit
der Verfolgung der Erzeugung, Modifikation und Löschung von Datenobjekten, die
der Transaktion T zugeordnet sind, während das derzeitige zweite
Ereignis verarbeitet wird.
-
Im
Schritt 214 wird das derzeitige Ereignis als das zweite
Ereignis in der Folge des vorliegenden Beispiels in einer in der
Technik gut bekannten Weise durch das Anwendungsprogramm verarbeitet,
das in dem Speicherteil 32a der ersten JVM 30 gespeichert ist.
Während
das zweite Ereignis in dieser Weise verarbeitet wird, wird das Datenobjekt 2 zum
Datenobjekt 2' geändert, und
der Zeiger von dem Datenobjekt 2' wird neu auf das neue Datenobjekt 4 gerichtet,
das in dem NEU-Speicher 32b für die Transaktion T geschaffen
wird, wie dies in 11 gezeigt ist. Das Daten-(Wurzel-) Objekt 1 bleibt
unverändert.
Im Schritt 216 wird beim Abschluss der Verarbeitung des
zweiten Ereignisses im Schritt 214 eine passende Antwort erzeugt
und an das Netzwerk 20 übertragen,
wie dies in 12 gezeigt ist. Während der
Verarbeitung des Ereignisses wird die Prüfpunkt-Umgebung 34 aktualisiert,
so dass entsprechend das Objekt 4 zu dem HINZUFÜGEN-Teil 34a hinzugefügt wird,
und das Datenobjekt 2' zum
dem MODIFIZIEREN-Teil 34b hinzugefügt wird.
-
Im
Schritt 218 trifft die erste JVM 30 die Feststellung,
wie dies weiter oben bezüglich
des ersten Ereignisses erläutert
wurde, ob das derzeitige (das heißt zweite) Ereignis das letzte
Ereignis der verarbeiteten Transaktion T ist. In dem vorliegenden
Beispiel bildet das zuletzt verarbeitete Ereignis (das heißt das zweite
Ereignis) nicht das letzte Ereignis der Transaktion T, und die Ausführung geht
von dem Schritt 218 zum Schritt 222 über.
-
Im
Schritt 222 werden die Datenobjekte als Datenabfall von
der Datenabfall-Sammelfunktion 36 gesammelt.
Entsprechend wird, weil kein Objekt auf das Datenobjekt 3 zeigt,
dieses Datenobjekt verworfen, und seine Identität wird in dem VERWERFEN-Teil 34c der
Prüfpunkt-Umgebung 34 aufgezeichnet.
Das neu geschaffene Datenobjekt 4 wird von dem NEU-Speicher 32b zu
dem ALT-Speicher 32c „befördert", wie dies in 13 gezeigt
ist.
-
Im
Schritt 224 wird der Inhalt des Prüfpunktes berechnet. An diesem
Punkt werden Änderungen an
dem Stapelraum (für
den Zweck der Prüfpunkt-Bildung)
nicht mehr länger
durch die Schreibsperre verfolgt. Die Prüfpunkt-Bildungsfunktion verwendet
Daten in den HINZUFÜGEN-
(34a), MODIFIZIEREN- (34b) und VERWERFEN- (34c)
Teilen der Prüfpunkt-Umgebung 34,
um die Änderungen
an dem Programmzustand festzustellen, die an die Reserve-JVM 40 übertragen
werden müssen.
-
Im
Schritt 226 werden die zu der Reserve-JVM 40 zu
kopierenden Objekten „rangiert". Die zu kopierenden
Objekte und die Liste von zu verwerfenden Objekten wird zusammen
mit irgendwelchen erforderlichen Verwaltungsdaten zu einer Prüfpunkt-Mitteilung
geformt, die zwischen JVM's
ausgesandt werden kann.
-
Im
Schritt 228 wird der im Schritt 226 erzeugte und
alle in der Prüfpunkt-Umgebung 34 gespeicherten
Objekte umfassende Prüfpunkt
der Prüfpunkt-Umgebung 44 der
zweiten JVM 40 zugeführt, wie
dies in 14 gezeigt ist. Die HINZUFÜGEN- (34a),
MODIFIZIEREN- (34b) und VERWERFEN- (34c) Teile
der Prüfpunkt-Umgebung 34 werden
von Daten befreit, die dem derzeitigen (das heißt zweiten) Ereignis der Transaktion
T zugeordnet sind.
-
Im
Schritt 230 wird der in der Prüfpunkt-Umgebung 44 gespeicherte
Prüfpunkt
zu dem ALT-Speicher 42c der zweiten JVM 40 bewegt,
wie dies in 15 gezeigt ist.
-
Zusätzlich werden
die Zeiger so modifiziert, dass Etiketten, die Objekte identifizieren,
auf die gezeigt wird, durch Positionsadressen in dem ALT-Speicher 42c ersetzt
werden, so dass von der ersten JVM 30 verwendete Zeiger
in korrekter Weise so umgewandelt werden, dass sie auf die gleichen
Objekte in der zweiten JVM 40 zeigen.
-
Die
Ausführung
der vorstehenden Schritte 228 und 230 wird vorzugsweise
unmittelbar nachfolgend zum Schritt 226 ausgeführt, so
dass der Transaktionszustand des Speichers in den JVM's 30 und 40 zu
allen Zeiten praktisch identisch ist. Nach dem Abschluss des Schrittes 230 kehrt
die Ausführung zum
Schritt 204 zurück.
-
Wie
dies weiter oben hinsichtlich der Fertigstellung des ersten Ereignisses
erläutert
wurde, ist zu erkennen, dass bei Fertigstellung des zweiten Ereignisses
der Zustand der Transaktion T in den ALT-Speichern 32c und 42c der
JVM's 30 bzw. 40 gemäß 15 praktisch
identisch ist. Daher kann irgendeine der JVM's 30 oder 40 das nächste (dritte) Ereignis
der Transaktion T verarbeiten.
-
Im
Schritt 204 warten die JVM's 30 und 40 auf das
nächste
Ereignis der Transaktion T von dem Netzwerk 20. Bei Empfang
des nächsten
Ereignisses, das heißt
des dritten Ereignisses in der Folge des vorliegenden Beispiels
werden übliche
Protokolle ausgeführt,
wie dies weiter oben erläutert
wurde, um festzustellen, welche der JVM's 30 oder 40 das nächste Ereignis
der Transaktion T verarbeitet, das von dem Netzwerk 20 empfangen
wird. Im vorliegenden Beispiel wird angenommen, dass die erste JVM 30 nicht
ausgefallen ist und verfügbar
ist, und daher die Verarbeitung der Transaktion fortsetzt. Daher wird
die erste JVM 30 zur Verarbeitung des nächsten Ereignisses der Transaktion
T bestimmt und wirkt weiterhin als die primäre JVM, während die zweite JVM 40 weiterhin
als Reserve-JVM wirkt.
-
Im
Schritt 206 erwarten die JVM's 30 und 40 den Empfang
des dritten Ereignisses der Transaktion T von dem Netzwerk 20.
Bei der Übertragung
des dritten Ereignisses der Transaktion T von dem Netzwerk 20,
wie dies in 16 gezeigt ist, empfangen beide
JVM's 30 und 40 das
Ereignis und zeichnen es in den jeweiligen Stapelspeichern 32 und 42 auf.
-
Im
Schritt 208 wird eine Feststellung von der ersten JVM 30 getroffen,
ob das im Schritt 206 empfangene Ereignis das erste Ereignis
einer neuen Netzwerk-Transaktion
T ist. Weil bei dem vorliegenden Beispiel das derzeitige Ereignis
das dritte Ereignis und nicht ein erstes Ereignis ist, geht die
Ausführung
zum Schritt 212 über.
Im Schritt 212 beginnt die Schreibsperre der ersten JVM 30 mit
der Verfolgung der Schaffung, Modifikation und des Verwerfens von Datenobjekten,
die der Transaktion T zugeordnet sind, während das derzeitige dritte
Ereignis verarbeitet wird.
-
Im
Schritt 214 wird das derzeitige Ereignis als das dritte
Ereignis in der Folge des vorliegenden Beispiels in einer in der
Technik gut bekannten Weise von dem in dem Speicher-Teil 32a der
ersten JVM 30 gespeicherten Anwendungsprogramm verarbeitet. Die
Verarbeitung des Ereignisses im Schritt 214 läuft vorzugsweise
bis zur Fertigstellung ab. Während
das dritte Ereignis auf diese Weise verarbeitet wird, wird das Wurzel-Datenobjekt 1 so
modifiziert, dass es das Datenobjekt 1' wird, das Datenobjekt 4 wird
so modifiziert, das es das Datenobjekt 4' wird, und der Zeiger von dem Datenobjekt 1' wird auf das
modifizierte Datenobjekt 4' umgelenkt,
wie dies in 17 gezeigt ist. Zusätzlich wird
ein neues Datenobjekt 5 in dem NEU-Speicher 32b geschaffen,
und der Zeiger von dem Objekt 4 wird auf das Objekt 5 gerichtet.
Im Schritt 216 und bei Abschluss der Verarbeitung des dritten
Ereignisses im Schritt 214 wird eine passende Antwort erzeugt
und zu dem Netzwerk 20 übertragen, wie
dies in 18 gezeigt ist. Während der
Verarbeitung des Ereignisses wird die Prüfpunkt-Umgebung 34 aktualisiert. Entsprechend
wird das Objekt 5 zu dem HINZUFÜGEN-Teil 34a hinzugefügt, und
die Datenobjekte 1' und 4' werden zu dem
MODIFIZIEREN-Teil 34b hinzugefügt.
-
Im
Schritt 218 führt
die erste JVM 30 eine Feststellung aus, wie sie weiter
oben bezüglich
des ersten Ereignisses beschrieben wurde, ob das derzeitige (das
heißt
das dritte) Ereignis das letzte Ereignis der Transaktion T ist,
die verarbeitet wird. Im vorliegenden Beispiel stellt das dritte
Ereignis das letzte Ereignis dar. Daher geht die Ausführung auf
den Schritt 220 über,
in dem die Verarbeitung der Transaktion T abgeschlossen ist und
alle Datenobjekte, die der Transaktion T zugeordnet sind, aus beiden
JVM's 30 und 40 entfernt
werden. Im vorliegenden Fall wird die Identität aller Objekte, die der Transaktion
T zugeordnet sind, effektiv zu dem VERWERFEN-Teil 34c der
Prüfpunkt-Umgebung 34 hinzugefügt. Eine
(abschließende)
Prüfpunkt-Mitteilung wird dann
von der primären
JVM 30 an die Reserve-JVM 40 gesandt, die anzeigt,
dass die Transaktion abgeschlossen ist, und dass alle gespeicherten
Zustandsobjekte verworfen werden können. Die primäre JVM 30 löscht dann
in der Prüfpunkt-Umgebung 34 alle
der Transaktion T zugeordneten Daten, und bei Empfang der von der
JVM 30 an die JVM 40 gesandten Mitteilung verwirft
die Reserve-JVM 40 in ähnlicher
Weise die Inhalte ihrer Prüfpunkt-Umgebung 42.
-
Die
Konfiguration der JVM's 30 und 40 kehrt dann
zu der in 1 gezeigten Konfiguration zurück, und
die Ausführung
kehrt zum Schritt 204 zurück.
-
Durch
die Verwendung der vorliegenden Erfindung werden vorhandene JVM-Funktionen, wie z. B.
die Datenabfall-Sammeleinrichtungen, so verbessert, dass Anwendungsprogramme,
die auf der JVM ablaufen, automatisch einer Prüfpunkt-Bildung zu einer oder mehreren Reserve-JVM's unterworfen werden
können.
Interne Schlüsselfunktionen
der JVM, wie z. B. deren Datenabfall-Sammelfunktion mit einer Schreibsperre,
sowie deren interne Kenntnis der Objektstrukturen, werden erneut
verwendet und erweitert, um eine maximale Effizienz zur automatischen Bestimmung
des Prüfpunkt-Inhaltes
zu bestimmen und um den Prüfpunkt
zur Übertragung
an eine oder mehrere Reserve-JVM's
zu codieren. Auf diese Weise wird die Konstruktion eines fehlertoleranten
Systems 10 erleichtert, was es ermöglicht, dass Transaktionen
kontinuierlich verarbeitet werden und verhindert, dass der Ausfall
einer einzelnen JVM (beispielsweise aufgrund eines Hardware-Ausfalls)
den Fehlschlag einer gesamten einzelnen Transaktion hervorruft.
Eine derartige Prüfpunkt-Bildung
kann erzielt werden, ohne dass irgendwelche Hinzufügungen oder
Modifikationen an dem Quellcode oder dem Objektcode der Anwendung
erforderlich sind, wodurch sowohl die Entwicklung als auch das Prüfen derartiger
Softwareprogramme ohne unnötige
Belastung vereinfacht wird. Die Prüfpunkt-Bildung ist weiterhin mit
der Datenabfall-Sammelfunktion
synchronisiert, so dass Daten, die einer Prüfpunkt-Bildung zwischen JVM's unterworfen sind,
zu einem Minimum gemacht werden. Eine derartige Prüfpunkt-Bildung
kann außerdem
schneller und zuverlässiger
sein, als die übliche
Prüfpunkt-Bildung.
-
Es
ist verständlich,
dass die vorliegende Erfindung viele Formen und Ausführungsformen
annehmen kann. Entsprechend können
verschiedene Abänderungen
an dem Vorstehenden durchgeführt werden,
ohne von dem Schutzumfang der Erfindung abzuweichen; beispielsweise
kann mehr als ein Anwendungsprogramm in eine einzige JVM 30 oder 40 geladen
werden, und die primäre
JVM kann den Prüfpunkt
an mehr als eine Reserve-JVM liefern.
-
In
einer anderen Variation kann irgendeiner eine Anzahl von unterschiedlichen
Arten von Datenabfall-Sammelalgorithmen realisiert werden.
-
In
einer weiteren Variation kann die Bestimmung der Inhalte des Prüfpunktes
so verfeinert werden, dass lediglich geänderte Teile von Objekten zwischen
Maschinen übertragen
werden, statt der vollständigen
Objekte, wie dies in der vorstehenden Beschreibung gezeigt wurde.
-
In
einer weiteren Variation können
die zu verwerfenden Objekte statt dass sie lediglich identifiziert werden,
in dem VERWERFEN-Speicher-Teil 34c gespeichert werden.
-
In
einer weiteren Variation kann der Schritt 230 umgangen
werden und der Prüfpunkt
kann in der Prüfpunkt-Umgebung 44 beibehalten
oder in einem anderen Speicher, wie z. B. einer Festplatte, gespeichert
werden, bis die JVM 30 ausfällt, wobei zu diesem Zeitpunkt
der Prüfpunkt
zu dem ALT-Speicher 42c des Stapelspeichers 42 bewegt
wird und die Zeiger in der vorstehend beschriebenen Weise modifiziert
werden. Zusätzlich
zu den vorstehend erläuterten
Vorteilen würde
eine derartige Variation Stapelspeicher 42 einsparen und
weniger Gesamt-Prozessorzeit von der JVM 40 benötigen.
-
In
einer weiteren Variation können
die Schritte 228 und 230 kombiniert werden, und
ein Prüfpunkt von
der ersten JVM 30 kann direkt an den Speicher 42c der
JVM 40 zugeführt
werden, ohne dass er zwischenzeitlich in der Prüfpunkt-Umgebung 44 gespeichert
wird. Zusätzlich
zu den vorstehend erläuterten Vorteilen
würde eine derartige
Variation effizienter sein und es der JVM 40 ermöglichen,
ohne die Prüfpunkt-Umgebung 44 konfiguriert
zu werden, wodurch ebenfalls Speicherressourcen eingespart werden.
-
Es
ist zu erkennen, dass die vorliegende Erfindung in Form von Computer-Software/Firmware geliefert
und damit auf einem computerlesbaren Medium verwirklicht werden
(wie z. B. einer CD-ROM), um auf die JVM heruntergeladen zu werden
oder um diese zu aktualisieren.
-
Nachdem
die vorliegende Erfindung unter Bezugnahme auf bestimmte ihrer bevorzugten
Ausführungsformen
beschrieben wurde, sei bemerkt, dass die beschriebenen Ausführungsformen
lediglich erläuternd
und nicht beschränkend
sind, und dass ein weiter Bereich von Abänderungen, Modifikationen, Änderungen
und Ersatzmöglichkeiten
in der vorstehenden Beschreibung in Betracht gezogen werden, und
dass in manchen Fällen
einige Merkmale der vorliegenden Erfindung ohne eine entsprechende Verwendung
anderer Merkmale verwendet werden können. Viele derartige Abänderungen
und Modifikationen können
von dem Fachmann als naheliegend und wünschenswert betrachtet werden,
nachdem er die vorstehende Beschreibung von bevorzugten Ausführungsformen
betrachtet hat. Entsprechend ist des richtig, dass die beigefügten Ansprüche breit
ausgelegt und in einer Weise betrachtet werden, die mit dem Schutzumfang
der Erfindung übereinstimmt.