-
Die
vorliegende Erfindung bezieht sich allgemein auf Computersoftware
und Computernetzwerkanwendungen. Spezieller bezieht sich dieselbe
auf Client-Konfigurationsdatenbanken und die Handhabung von Transaktionen
in einer Konfigurationsdatenbank.
-
Ein
Typ eines herkömmlichen
Computernetzwerks umfaßt
das Verbinden einer Reihe von Personalcomputern, die als Clients
bezeichnet werden (beispielsweise Sun SPARC Workstations oder IBM
PCs) mit einem oder mehreren Server-Computern. Die Client-Computer
sind im allgemeinen unabhängig
und enthalten in ihrem eigenen Speicher einen Großteil der
Informationen, die benötigt
werden, um Benutzeranwendungen durchzuführen und Netzwerkoperationen
durchzuführen.
Das heißt,
daß dieselben
Informationen bezüglich
ihrer eigenen Konfiguration sowohl hinsichtlich Software- als auch
Hardware-Fähigkeiten
und -Anforderungen enthalten. Die Client-Computer greifen typischerweise
aufgrund einer Vielzahl von Gründen
auf die Netzwerk-Server zu, wie z.B. des Zugreifens auf Netzwerksoftwareanwendungen,
des Sendens und Empfangens von e-Mails, des Wiedererlangens und
Speicherns von Informationen auf einer Netzwerkdatenbank. Jedoch befinden
sich Informationen, die für
einen speziellen Client-Computer spezifisch sind, im allgemeinen
auf dem Client-Computer. Diese Informationen können beispielsweise die Speichermenge
oder Datenbustypen, Hardwarespezifikationen, wie z.B. den Typ des Datenbusses
oder zusätzlicher
Prozessoren, umfassen. Da die Client-Computer relativ unabhängig sind und
ihre eigenen Konfigurationsinformationen speichern (weshalb dieselben
nicht auf dem Server-Computer verfügbar sind), wurde die Aufgabe
der Daten- und Anwendungs-Verwaltung auf einem Client-Computer zunehmend
mühsam.
-
Obwohl
es möglich
ist, kleinere Änderungen oder
Instandsetzungen für
Anwendungen, die sich auf einem Server auf dem Netzwerk befinden,
zu den Client-Computern auszubreiten, fordert jede signifikante
Aktualisierung oder Instandsetzung, oder Installation einer neuen
Anwendung, die jeden Client-Computer beeinflußt, daß durch einen Netzwerkadministrator
auf jeden Client-Computer einzeln zugegriffen und derselbe aktualisiert
wird. Mit der zunehmenden Anzahl von Computern, die in Netzwerken
verbunden sind, die im Bereich von einigen zehn bis zu Tausenden
in bestimmten Unternehmen liegt, wurde die Belastung des Installierens
von größeren Überarbeitungen
oder Aktualisierungen der Anwendungssoftware oder der allgemeinen
Konfigurationssoftware aufwendig, ineffizient und zeitraubend.
-
Gegenwärtigen Konfigurationsdatenbanken in
verteilten Rechnerumgebungen, speziell denjenigen, die Netzwerkcomputer
verwenden, fehlen adäquate
Transaktionshandhabungs-Werkzeuge und -Merkmale. Beispielsweise
unterstützen
Konfigurationsdatenbank-Systeme und -Protokolle keine vollständig funktionale
Sperrfähigkeit,
um Nur-Lese-Transaktionen oder exklusive Transaktionen zu handhaben.
Ein weiteres Merkmal, das in solchen Datenbank-Systemen und -Protokollen,
wie sie oben beschrieben sind, fehlt, ist das, was als "Zerlegbarkeit" ("atomicity") bezeichnet wird,
oder die Fähigkeit, zu
garantieren, daß eine
Transaktion in der Datenbank entweder vollständig abgeschlossen oder nicht abgeschlossen
wurde. Diese Merkmale sind wichtige praktische Betrachtungen bei
der täglichen
Verwendung einer Konfigurationsdatenbank. Überdies leiden Transaktionen
in bekannten Konfigurationsdatenbanken an der Unsichtbarkeit für die Anwendung; in
anderen Worten heißt
das, daß die
Anwendung die Transaktion und, wie die Transaktion durchgeführt werden
sollte, explizit identifizieren muß. Dies steht im Gegensatz
dazu, einfach zu spezifizieren, was getan werden muß, und zu
ermöglichen,
daß die
Konfigurationsdatenbank die Transaktion auf die effizienteste Art
und Weise ohne Intervention von der Anwendung handhabt.
-
Daher
wäre es
im Zusammenhang mit der Handhabung von Transaktionen in der Konfigurationsdatenbank
erwünscht,
eine Transaktionshandhabung in einer Konfigurationsdatenbank zu
besitzen, die eine Zerlegbarkeit und ein Sperren ermöglicht.
Es wäre
ferner erwünscht,
ein Transaktionshandhabungsgerüst
zu haben, das sich als ein Kernbasismerkmal verhält, dahingehend, daß Anwendungen nicht
den Abschluß der
Transaktion anweisen oder überwachen
müssen,
wenn dasselbe wählt,
dies nicht zu tun. Die Anwendung sollte einfach anzeigen, daß sie eine
spezielle Operation abschließen
will und daß die
Konfigurationsdatenbank alles tun sollte, was ihres Erachtens notwendig
ist, um die Zerlegbarkeit der Operation zu garantieren.
-
Die
EP 0 758 114 A1 zeigt
ein Transaktionsverarbeitungssystem, bei dem eine Mehrzahl von Servern
durch ein Kommunikationsnetzwerk miteinander verbunden sind, wobei
Resourcen, wie beispielsweise Datenbanken, Datendateien, Speicherbänder oder
dergleichen über
diese Server verteilt sind. Ansprechend auf eine Transaktion beauftragt der
Server, der die Transaktion empfängt
und ein Koordinator ist, Teilnehmer-Server zum Aktualisieren ihrer
Resourcen. Ein Protokoll zum Aufzeichnen der Gegenstände der
Aktualisierungsinformationen ist entweder bei dem Koordinator oder
den Servern vorgesehen. Jedem Gegenstand von Aktualisierungsinformationen
in diesem Protokoll wird ein Identifikationscode der Transaktion
angehängt.
Jeder der Teilnehmer aktualisiert die verteilte Resource ansprechend
auf die Gegenstände
der Aktualisierungsinformationen von dem Koordinator. Bei einem
Versagen von einem beliebigen Teilnehmer bezüglich des Aktualisierens der
Resourcen wird daraufhin ein Wiederherstellungsprozeß für diese
Resource durchgeführt.
-
Die
US 5,410,691 A zeigt
eine Netzwerkdatenbank, die in einer Mehrzahl von Domänen in einer logischen
Hierarchie angeordnet ist. Jede Domäne der Hierarchie stellt einen
Informationskörper
dar, der einer Gruppe von Benutzern oder einer Gruppe von Computern,
die einen logischen Bezug zu demselben aufweisen, zugeordnet ist.
Ein Relativ-Namenschema ist implementiert, bei dem in einer Domäne die Namen
von lediglich der Mutter- und Kind-Domäne gespeichert ist. Dies ermöglicht,
daß eine
Rekonfiguration des Netzwerks erreicht werden kann, ohne die Datenbankstruktur
zu verändern.
-
Es
ist die Aufgabe der vorliegenden Erfindung, ein neuartiges verbessertes
Verfahren zum Aktualisieren einer Konfigurationsdatenbank zu schaffen.
-
Diese
Aufgabe wird durch ein Verfahren nach Anspruch 1 gelöst.
-
Eine
weitere Aufgabe der vorliegenden Erfindung besteht darin, eine neuartige
und verbesserte Vorrichtung und ein Verfahren zum Handhaben von Transaktionen
in einer Konfigurationsdatenbank zu schaffen.
-
Diese
Aufgabe wird durch eine Vorrichtung nach Anspruch 13 und ein Verfahren
nach Anspruch 14 gelöst.
-
Eine
weitere Aufgabe der vorliegenden Erfindung besteht darin, Computer-lesbare
Medien zur Aktualisierung von Konfigurationsdatenbanken und zur
Handhabung von Transaktionen in Konfigurationsdatenbanken zu schaffen.
-
Diese
Aufgabe wird durch Computer-lesbare Medien nach den Ansprüchen 15
und 16 sowie Computerdatensignale nach den An sprüchen 17 und 18 gelöst.
-
Nachfolgend
wird hierin ein Verfahren zum Handhaben von Transaktionen und zum
Aktualisieren einer Konfigurationsdatenbank gemäß der vorliegenden Erfindung
beschrieben. Gemäß einem
Aspekt der Erfindung bestimmt der Transaktionsmechanismus, ob ein
neuer Knoten zu der Konfigurationsdatenbank hinzugefügt werden
soll, oder ob ein existierender Knoten durch die Transaktion modifiziert werden
soll. Entsprechend der Tatsache, ob ein neuer Knoten zu der Konfigurationsdatenbank
hinzugefügt
werden soll oder ein existierender Knoten modifiziert werden soll,
wird eine Sperre auf dem Knoten erhalten. Ein Identifizierer oder
eine Bezeichnung wird der Transaktion, die die Sperre bewirkte,
zugewiesen, wobei an diesem Punkt die Modifikationen bezüglich der
Konfigurationsdatenbank durchgeführt werden.
Die Transaktion, die die Modifikationen bewirkt, wird festgeschrieben,
indem die Sperre gelöst wird,
wenn die Modifikationen erfolgreich sind. Die Transaktion wird abgebrochen,
wenn die Modifikationen fehlschlagen.
-
Bei
einem bevorzugten Ausführungsbeispiel bestimmt
der Sperrmechanismus, ob die Transaktion, die versucht, die Sperre
zu erhalten, eine Blockier- oder Nicht-Blockier-Transaktion ist, was bestimmen wird,
ob der Teilprozeß (thread)
der Transaktion in einer Warteschlange plaziert wird, um darauf
zu warten, daß die
Sperre gelöst
wird. Bei einem weiteren bevorzugten Ausführungsbeispiel wird ein neuer Knoten
zu der Konfigurationsdatenbank hinzugefügt, wenn Daten, die sich nicht
auf einen existierenden Knoten beziehen, durch die Transaktion erzeugt
werden, wobei ein existierender Knoten aktualisiert wird, wenn Daten,
die durch die Transaktion erzeugt werden, sich auf den existierenden
Knoten beziehen. Bei noch einem weiteren bevorzugten Ausführungsbeispiel
wird die Datenbank in einen Anfangszustand zurückgebracht, wenn die Transaktion
abgebrochen wird, indem alle Aktualisierungen in der Transaktion, die
erfolgreich durchgeführt
worden sind, rückgängig gemacht
werden.
-
Diesem
folgt das Lösen
der Sperre auf dem Knoten und das Benachrichtigen eines Ereignisverwalters,
daß die
Sperre gelöst
wurde.
-
Gemäß einem
weiteren Aspekt der Erfindung wird eine Vorrichtung zum Handhaben
von Transaktionen in einer verteilten Konfigurationsdatenbank, die
einen Anfangszustand und mehrere Unterbäume aufweist, beschrieben.
Eine Transaktionsschnittstelle mit privaten und öffentlichen Segmenten, nimmt
Transaktionen, die durch eine Anwendung initiiert werden, die in
der Konfigurationsdatenbank durchgeführt werden, an. Ein Ereignisbenachrichtigungsverwalter
versetzt Transaktionen, die darauf warten, daß eine Sperre gelöst wird,
in Alarmbereitschaft, wenn eine Sperre-Halten-Transaktion eine Mitteilung
eingibt, die anzeigt, daß die
Sperre gelöst wurde.
Eine Ereigniswarteschlange speichert klassifiziert basierend auf
den Transaktionen Daten, die sich auf Transaktionen beziehen, die
bezüglich
der Konfigurationsdatenbank durchgeführt werden. Das private Segment
der Transaktionsschnittstelle stellt sicher, daß eine Transaktion eine Sperre
nicht für eine
längere
Dauer aufrecht erhält
als es für
die Transaktion erforderlich ist.
-
Bevorzugte
Ausführungsbeispiele
der vorliegenden Erfindung werden nachfolgend. bezugnehmend auf
die beiliegenden Zeichnungen näher
erläutert.
Es zeigen:
-
1 ein
Blockdiagramm, das Komponenten einer Computernetzwerkkonfiguration
zeigt, die ein System-weites Datenschema gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung zeigen;
-
2 eine
Darstellung einer n-Weg-Baumstruktur, die eine Client-Schema-Hierarchie
gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung darstellt;
-
3 ein
Blockdiagramm, das eine Struktur eines JSD-Server-Schemas (JSD =
Java-System-Datenbank) gemäß ei nem
Ausführungsbeispiel der
vorliegenden Erfindung zeigt;
-
4 ein
Blockdiagramm, das eine Klassenhierarchie, die Klassen und Objekte
enthält,
einer Transaktionshandhabung in einer Konfigurationsdatenbank gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung zeigt;
-
5 ein
Flußdiagramm,
das ein Verfahren einer Zwei-Phasen-Sperre eines Eintrags in die
Konfigurationsdatenbank gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung zeigt;
-
6 ein
Flußdiagramm,
das detaillierter einen Schritt 508 von 5 zeigt,
in dem die Aktualisierung gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung durchgeführt wird;
-
7 ein
Flußdiagramm,
das detaillierter einen Schritt 514 von 5 zeigt,
in dem eine Transaktionsabbruchphase gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung gezeigt ist;
-
8 ein
Blockdiagramm, das eine Ereigniswarteschlange gemäß einem
Ausführungsbeispiel der
vorliegenden Erfindung zeigt; und
-
9 ein
Blockdiagramm eines typischen Computersystems, das zur Implementierung
eines Ausführungsbeispiels
der vorliegenden Erfindung geeignet ist.
-
In
den verschiedenen Zeichnungen ist ein Daten-Gerüst oder -Schema und ein Verfahren
zum Handhaben von Transaktionen, die auf das Datenschema gerichtet
sind, unter Computern in einem Computernetzwerk beschrieben. Die
vorliegende Erfindung offenbart eine Hierarchie oder ein Datenschema
zum Darstellen und Speichern von Konfigurationsinformationen und verwandten
Informationen in einer Systemdatenbank. Dieselbe offenbart ferner Möglichkeiten,
um Benutzertransaktionen, die Daten in dem Datenschema aktualisieren
oder modifizieren, zu handhaben. Zu Zwecken der Darstellung eines Ausführungsbeispiels
der vorliegenden Erfindung wird eine Java-System-Datenbank (JSD) untersucht. Bei
anderen bevorzugten Ausführungsbeispielen kann
die Datenbank auf anderen Plattformtypen arbeiten. Die JSD des beschriebenen
Ausführungsbeispiels
ist ein einzelnes Untersystem, das zumindest zwei Hauptunterkomponenten
oder Unterschemata aufweist: das Client-Schema und das Server-Schema.
Bei dem beschriebenen Ausführungsbeispiel sind
Daten, die sich auf einen Client beziehen, in einem Client-Schema
gespeichert, das sich in dem Client-Speicher befindet. Konfigurationsdaten
für jeden der
Clients sind in einem Server-Schema gespeichert, das sich auf einem
Netzwerkserver befindet. Die Konfigurationsinformationen für jeden
Client, der auch als Untersystem bezeichnet wird, sind in dem Server-Schema
gespeichert. Dies steht im Kontrast zu herkömmlichen Netzwerken, bei denen
Konfigurationsinformationen bezüglich
eines Client auf der Client-Maschine fest codiert oder gespeichert
sind. Das Datenschema der vorliegenden Erfindung ermöglicht,
daß ein
Netzwerkadministrator Konfigurationsinformationen für jeden
der Computer in dem Netzwerk von einem zentralen Ort aus, beispielsweise von
einem einzelnen Server aus, handhabt. Daher können alle Softwareaktualisierungen,
Versionsaktualisierungen oder Installationen von neuen Anwendungen,
die die Kenntnis einer und einen Zugriff auf eine Untersystemkonfiguration
erfordern, von dem zentralen Ort aus implementiert und zu den einzelnen Clients
ausgebreitet werden. Benutzer auf den Client-Maschinen müssen Anwendungen
nicht verlassen, wobei das Netzwerk überdies nicht zur Wartung heruntergefahren
werden muß,
um die neue Aktualisierung oder Version der Anwendung zu installieren oder
auszubreiten.
-
1 ist
ein Blockdiagramm, das Komponenten einer Computernetzwerkkonfiguration,
die ein System-weites Datenschema gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung zeigt, zeigt. Bei dem beschriebenen Ausführungsbeispiel
ist das System-weite Datenschema als ein Java-System-Datenbank JSD
(101) dargestellt, die aus einem Client-Schema 103 besteht,
das sich in einer Client-Maschine 105 als Teil des Netzwerks 107 befindet.
Ein Server-Schema 111 befindet sich auf einem Server-Computer 109,
der Teil des Netzwerks 107 ist.
-
2 ist
eine Darstellung einer n-Weg-Baumstruktur, die eine Client-Schema-Hierarchie 103 gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung darstellt. Die Hierarchie des Client-Schema 103 und
die Hierarchie des Server-Schemas 111 werden
unter Verwendung eines n-Weg-Baums offenbart. An der Wurzel des
Baums befindet sich ein Wurzeleintrag 201, der keine Daten enthält und das
einzige Knotengerüst
in der Hierarchie ist, das auf sich selbst Bezug nimmt. Eine erste Ebene
von Knoten 203 in dem Client-Schema 103 definiert
kollektiv einzelne Namensräume
in dem generischen Client-Schema. Die Ebene, die die Namensraumeinträge enthält, ist
die erste Ebene 203 in der Hierarchie unter dem Wurzeleintrag 201.
-
Bei
dem beschriebenen Ausführungsbeispiel existieren
sechs Namensräume
in dem generischen Client-Schema 103. Bei anderen bevorzugten
Ausführungsbeispielen
können
mehr oder weniger Namensräume
abhängig
von den Bedürfnissen
einer speziellen Netzwerkkonfiguration existieren. Bei dem beschriebenen
Ausführungsbeispiel
sind die Standard-Namensräume
der oberen Ebene für
den JSD-Client SOFTWARE, GERÄTE,
SCHNITTSTELLE, SOFTWAREKONFIGURATION, ALIAS und TEMP. Beispielsweise
beginnt der Namensraum SOFTWARE an einem Knoten 205 und
enthält
alle Knoten und Datenverzweigungen, die sich von dem Knoten 205 verzweigen.
Die spezifischen Einträge
in der Ebene 203 der Hierarchie sind Wurzeln von Unterbäumen, die
die eindeutigen Namensräume
definieren. Alle Einträge
in einem speziellen Namensraum, wie z.B. SOFTWARE, sind Einträge, die
sich auf Konfigurationsdaten bezüglich
Softwareanwendungen für
den Client 105 beziehen. Einträge in dem Da tenschema der vorliegenden
Erfindung sind aus einem eindeutigen Namen, einer Liste von Kindern (Einträgen unter
dem gegebenen Eintrag) und einem Satz von Tupeln gebildet. Jedes
Tupel enthält
einen Eigenschaftsnamen oder einen zugeordneten Eigenschaftswert.
Beispielsweise kann bei einem Textverarbeitungsprogramm ein Eigenschaftsname "Font" lauten, während der
Eigenschaftswert Palentino lauten kann. In gleicher Weise sind alle
Einträge
unter dem Namensraum GERÄT 207 Einträge, die
sich auf Konfigurationsinformationen der Client-Maschine 105, auf der sich
das Client-Schema 103 befindet, beziehen. Jeder Eintrag
in der Hierarchie kann sowohl als ein Eintrag in einem Unterbaum
als auch der Wurzel eines Unterbaums, die abstammende Einträge oder
Kinder-Knoten aufweist, wirksam sein.
-
Wie
in 2 gezeigt ist, besitzt jeder Eintrag in dem Baum
eine einzelne Mutter und kann mehrere Kinder-Knoten aufweisen. Ein
Namensraum, wie z.B. der Namensraum SOFTWARE 209 ist ein
speziell designierter Unterbaum, der Einträge enthält, die sich auf Konfigurationsdaten
bezüglich
der Software für einen
speziellen Client, wie z.B. den Client 105, beziehen. Wie
in 2 gezeigt ist, sind bei dem beschriebenen Ausführungsbeispiel
Namensräume
immer direkte Abkömmlinge
eines Wurzeleintrags 201, der auch als eine Superwurzel
bezeichnet wird. Bei anderen bevorzugten Ausführungsbeispielen können Namensräume in anderen
Ebenen in der Hierarchie definiert sein, und müssen nicht direkt von der Wurzel 208 abstammen.
Die Standardnamensräume
des JSD-Schema-Client werden während
der Anlauf- oder Boot-Prozedur des Client-Computers erzeugt. Jeder der Namensräume ist
bei dem beschriebenen Ausführungsbeispiel
bei allen Implementierungen der Java-Plattform verfügbar. Die
sechs Namensräume
sind gut bekannte Namensräume,
die durch die Java-Plattform initialisiert werden. Andere dynamisch aufgebaute
Namensräume
können
zu den Standard-Datenbanknamensräumen
nach der Initialisierung hinzugefügt werden.
-
Jeder
Namensraum wird durch einen vorgegebenen Namensraum verwalter gehandhabt.
Der Namensraumverwalter steuert, wie die Einträge in den Namensraum gespeichert
werden und wie auf dieselben zugegriffen wird. Der Verwalter implementiert
eine Standardschnittstelle, die die Sicherheits-, Speicher- und Eigentums-Attribute
jedes Eintrags in dem Namensraum exportiert.
-
Beispielsweise
enthält
der Namensraum SOFTWARE 209 eine Liste von installierten
und/oder verfügbaren
Systemdiensten, beispielsweise Gerätetreibern, Benutzeranwendungen
und Benutzerkonfigurationsinformationen. Der Software-Namensraum ist
der einzige beständige
Namensraum in dem Client-Schema, dahingehend, daß ein Server eine Backup-Speicherung
für alle
Einträge
in diesem Namensraum liefert. Ein beständiger Namensraum oder Eintrag
ist im Gegensatz zu einem transienten Namensraum ein Eintrag, der
an einem beständigen (nichtflüchtigen)
Speicherort gespeichert werden muß. Ein Beispiel von beständigen Einträgen sind Konfigurationsinformationen,
die sich auf Benutzerumgebungen beziehen, die in einem beständigen Speicher
gespeichert werden müssen.
Wenn sich ein Benutzer anmeldet, muß die letzte gespeicherte Umgebung
des Benutzers wiedergewonnen werden, so daß er oder sie die Umgebung
nicht wieder einstellen muß.
Beständige
Einträge
sind Einträge,
die an einem dauerhaften Speicherort gespeichert und von demselben
wiedererlangt werden können.
Beständige
und transiente Namensräume
werden statisch getrennt, wenn Namensräume erzeugt werden. Es ist nicht
erlaubt, daß sich
ein beständiger
Eintrag in einem transienten Namensraum befindet, und/oder es ist
nicht erlaubt, daß sich
ein transienter Eintrag in einem beständigen Namensraum befindet.
Bei dem beschriebenen Ausführungsbeispiel
werden beständige
Einträge
auf einem Fern-JSD-Server gespeichert. Bei dem beschriebenen Ausführungsbeispiel existieren
unter dem Namensraum SOFTWARE vier Kategorien: Anwendung, System,
Dienst und Öffentlichkeit.
Bei dem beschriebenen Ausführungsbeispiel unter
Verwendung der Java-Plattform sind einige der Einträge in dem
Namensraum SOFTWARE unter Verwendung von eindeutigen Java-Namensgebungskonventionen
angeordnet, während
andere Einträge,
die sich nicht auf Java beziehen, Namensgebungskonventionen basierend
auf spezifischen Anwendungen aufweisen. Bei dem beschriebenen Ausführungsbeispiel
sind Firmennamen, wie z.B. IBM, Sun oder Lotus, Namen wie z.B. com.IBM, com.Sun
und com.Lotus gegeben. Diese Firmennamen halten firmenspezifische
Informationen auseinander. Eintragsnamen unter dem Firmennamen sind firmenspezifisch.
-
Wie
beschrieben wurde, ist der Namensraum SOFTWARE 209 der
einzige Namensraum der sechs, der bei dem beschriebenen Ausführungsbeispiel
einen beständigen
Speicher aufweist. Die anderen Namensräume, wie z.B. der Namensraum
GERÄT 207,
besitzen einen transienten Speicher. Einträge in diesen Namensräumen gehen
verloren, wenn der Client-Computer abgeschaltet wird. Dies gilt
bei dem beschriebenen Ausführungsbeispiel,
da die fünf
transienten Namensräume
Daten speichern, die sich spezifisch auf einen Client-Computer beziehen.
Bei dem beschriebenen Ausführungsbeispiel enthält der Namensraum
SOFTWARE Anwendungskonfigurationsinformationen, die gespeichert
werden müssen,
nachdem der Computer abgeschaltet wird.
-
Unter
dem Software-Namensraum befinden sich vier Kategorien: Anwendung,
System, Dienst und Öffentlichkeit.
Unter Verwendung der Anwendungskategorie als einem Beispiel enthält ein Eintrag com.Netscape 213 den
eindeutigen Firmennamen (beispielsweise Netscape), wobei sich unter
dem Eintrag com.Netscape 213 ein Eintrag für eines
der Produkte von Netscape, Netscape Navigator, befindet. Unter dem
Eintrag 215 befinden sich firmenspezifische Informationen 217,
die sich auf den Netscape Navigator beziehen.
-
Einträge 219, 221 und 223 sind
Einträge
für andere
Verkäufer,
die ebenfalls Einträge
besitzen, die ähnlich
zu dem Eintrag 215 sind. Bei dem beschriebenen Ausführungsbeispiel
spiegelt die Struktur des Geräte-Namensraums 225 den
Eingabe/Ausgabe-Bus und/oder den peripheren Bus und/oder die Vorrichtung,
die auf dem Client vorliegen, wieder. In anderen Worten heißt das,
daß die
physische Anschließbarkeit
von Bussen und Geräten
als ein Baum von Einträgen
dargestellt ist, wobei ein spezieller Bus die Mutter ist und Blatt-Einträge Konfigurationsdaten bezüglich der
Geräte
enthalten.
-
In
dem Software-Namensraum enthält
die Blattknotenebene der Hierarchie Daten 227, die konfigurationsspezifisch
sind und abhängig
davon, wie die Anwendung, beispielsweise der Netscape Navigator,
die spezifischen Daten auf der Blattknotenebene anfordern will,
angeordnet sind. Für
eine Textverarbeitungsanwendung würden die Blattknoteneinträge spezifische
Informationen enthalten, beispielsweise Font- und Wörterbuch-Definitionen,
sowie weitere Konfigurationsdaten vom Textverarbeitungstyp.
-
Die
Namensräume
in der Server-Schema-Komponente der JSD sind beständige Speicherräume; d.h.,
dieselben bleiben, nachdem der Client-Computer abgeschaltet ist.
Bei dem beschriebenen Ausführungsbeispiel
existieren zwei Namensräume
in dem Server-Schema: Maschine und Benutzer. 3 ist ein
Blockdiagramm, das eine Struktur eines JSD-Serverschemas gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung zeigt. Dasselbe zeigt den Server-Computer 109 und
das Server-Schema 111 von 1 detaillierter.
An der Spitze des n-Weg-Baums befindet sich ein Wurzeleintrag 301,
der bei dem beschriebenen Ausführungsbeispiel
einen Namensraum CONFIG darstellt. Wie erwähnt wurde, existieren in dem
Server-Schema zwei Namensräume.
Der Bereich 303 stellt den Maschinen-Namensraum mit einem
Maschinenknoten 305 dar. Der Bereich 307 stellt
den Benutzernamensraum mit einem Benutzerknoten 309 dar.
-
Der
Maschinennamensraum 303 ist bei dem beschriebenen Ausführungsbeispiel
aus drei Kategorien gebildet. Bei anderen bevorzugten Ausführungsbeispielen
kann der Maschinennamensraum 303 mehr oder weniger Unterkategorien
aufweisen, abhängig
von der Plattform und den Anforderungen des Netzwerks. Die drei
Kategorien oder Unterbereiche sind Plattform 311, Identifizierer 313 und
Profil 315. Unter Plattform 311 be findet sich
eine Anzahl von Einträgen,
die sich auf spezifische Computerhersteller beziehen, wie z.B. Sun
Microsystems und IBM Corporation.
-
Wie
vorher erwähnt
wurde, offenbart die vorliegende Erfindung ferner ein System für eine Transaktionshandhabung.
Bei dem beschriebenen Ausführungsbeispiel
besitzt die Transaktionshandhabung eine Transaktions-API (API =
application program interface = Anwendungsprogrammschnittstelle),
die als ein Behälter
oder ein Transaktionshandhabungsobjekt beschrieben werden kann,
die jeden Typ eines abstrakten Eintrags handhabt. Ein Eintrag, d.h.
eine spezielle Operation, kann in dieser Transaktions-API oder dem
Container plaziert werden. Die Transaktions-API ist für eine Anwendung
eine Möglichkeit,
um das Durchführen
einer Transaktion zu erreichen, und besitzt zwei Komponenten: eine
Sperr-API und eine Ereigniswarteschlange, die detaillierter nachfolgend beschrieben
werden. 4 ist ein Blockdiagramm, das
eine Klassenhierarchie zeigt, die Klassen und Objekte einer Transaktionshandhabung
bei einer Konfigurationsdatenbank gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung enthält. Eine
Basiseintrag-Klasse 402 ist eine abstrakte Klasse, dahingehend,
daß in
derselben das Verhalten von Objekten definiert ist, jedoch kein
tatsächliches
Objekt selbst. Dieselbe enthält
die Kern-API, die wiederum eine Transaktions-API der vorliegenden
Erfindung enthält.
Ein Teil der Basiseintrag-Klasse 402 ist privat, der als
Bereich 404 gezeigt ist, während der Rest öffentlich
ist. Alle Transaktionen in der Konfigurationsdatenbank sind in der
privaten Basiseintrag-Klasse 404 implementiert. Indem somit
der Transaktions-API-Abschnitt der Basiseintrag-Klasse 402 privat
gehalten ist, kann das Transaktionshandhabungsgerüst der vorliegenden
Erfindung sicherstellen, daß Transaktionen
korrekt durchgeführt
werden, dahingehend, daß Transaktionen
den Wurzelknoten eines Unterbaums nicht sperren, wie detaillierter
nachfolgend beschrieben wird.
-
Die
Privat-Basiseintrag-Klasse 404 ist im wesentlichen der Transaktionsbehälter, der
oben genannt ist. Ein Eintragsobjekt 406 wird in der Basiseintrag-Klasse 402 "plaziert", damit eine Transaktion stattfindet.
Beispiele bestimmter Fälle
von Kern-API-Funktionen sind ein Ereignisbezeichnungsverwalter 408 und
ein Sperrverwalter 410, die nachfolgend detaillierter beschrieben
werden. Bei weiteren bevorzugten Ausführungsbeispielen kann die Kern-API
eine beliebige andere Anzahl von Transaktionen als die, die unten
beschrieben werden, aufweisen. Ein wichtiges Merkmal der Kern-API
oder der Transaktions-API besteht darin, daß dieselbe ein Teil der Privat-Basiseintrag-Klasse 404 ist
und daher vor öffentlichen
Basiseintrag-Unterklassen und destruktiven Transaktionen (beispielsweise
Transaktionen, die eine Sperre halten) geschützt sind. Um die Klassenhierarchie
abzuschließen,
sind in 4 ferner eine Systemeintrag-Klasse 412 und
eine Beständig-Systemeintrag-Klasse 414 gezeigt.
Diese zwei Klassen befinden sich außerhalb der Privat-Basiseintrag-Klasse 404 und
sind daher Teil der öffentlichen Basiseintrag-Klasse.
Die Systemeintrag-Klasse 412 enthält transiente Namensräume in dem
Client-Schema, wie oben beschrieben ist. Bei dem beschriebenen Ausführungsbeispiel
umfassen diese GERÄT, SCHNITTSTELLE,
KONFIGURATION, ALIAS und TEMP. Bei anderen bevorzugten Ausführungsbeispielen
kann die Systemeintrag-Klasse 412 andere Namensräume enthalten,
abhängig
von den Bedürfnisses
des Netzwerks und seiner Benutzer. Bei dem beschriebenen Ausführungsbeispiel
enthält
die Beständig-Systemeintrag-Klasse 414 den
einzigen beständigen
Namensraum Software, wie oben beschrieben wurde.
-
Das
Sperr-API- und Handhabungs-Merkmal, das als Fall 410 der
Eintragsklasse 406 in 4 gezeigt
ist, ist bei der JSD-Konfigurationsdatenbank
der vorliegenden Erfindung ein zweiphasiger Sperrprozeß. In der
ersten Phase wird ein Eintrag gesperrt, während in der zweiten Phase
eine Aktualisierung (oder im Fall eines Fehlschlagens eine Rückkehr) durchgeführt wird.
Die Sperr-API, ein Eintrag in der privaten Transaktions-API, garantiert,
daß keine
Anwendung eine Blockierung aufweisen wird oder einen Eintrag festhalten wird
(spezifisch die Wurzel eines Unterbaums), wodurch andere Transaktionen,
die auf Knoten in einem Unterbaum warten, ausgesperrt werden. Bei
dem beschriebenen Ausführungsbeispiel
wird dieselbe beispielsweise garantieren, daß keine Sperre auf dem Wurzeleintrag
des Client-Schemas existiert.
-
5 ist
ein Flußdiagramm,
das ein Verfahren einer Zwei-Phasen-Sperre
eines Eintrags bei der Konfigurationsdatenbank gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung zeigt. In einem Schritt 502 versucht
die Anwendung, den geeigneten Wurzelknoten eines Unterbaums in einem
Namensraum zu sperren. Wenn ein neuer Knoten zu dem Schema hinzugefügt wird,
wird der Mutterknoten des Unterbaums, der aktualisiert wird, gesperrt, während ein
neuer Blattknoten hinzugefügt
wird. Wenn ein existierender Blattknoten aktualisiert wird, muß nur der
Blattknoten gesperrt werden.
-
Um
die Veranschaulichung der verschiedenen Szenarien bei einer zweiphasigen
Sperre des beschriebenen Ausführungsbeispiels
zu unterstützen,
sowie weitere Merkmale der Transaktionshandhabung, die nachfolgend
beschrieben wird, ist das Folgende ein Beispiel einer Transaktion
und dafür, wie
das JSD-Schema ausgeführt
wird. Wie oben erwähnt
wurde, liefert das JSD-Schema (das Client-Schema und das Server-Schema)
eine Datenbank zum Speichern und Verarbeiten von Konfigurationsinformationen.
Einer der Namensräume
in dem Client-Schema
ist ein Geräte-Namensraum,
während ein
weiterer der Schnittstellen-Namensraum, der in 2 gezeigt
ist, ist. Wenn ein Benutzer die Einstellungen eines Zubehörgeräts, das
mit dem Computer des Benutzers verbunden ist, hinzufügt oder
modifiziert, werden diese Namensräume typischerweise ausgeführt. Wenn
ein Benutzer beispielsweise einen neuen Drucker an seinen Computer
anschließt,
werden der Geräte-
und der Schnittstellen-Namensraum modifiziert. Wenn der Drucker
zuerst angeschlossen wird, tastet das Betriebssystem die Zubehörgerät-Busverbindungen
ab und findet heraus, daß ein neues
Zubehörgerät an den
Bus angeschlossen ist. Das Betriebssystem durchläuft ein Verfahren zum Bestimmen,
welcher Gerä te-Typ
oder Hardware-Typ hinzugefügt
wurde, und welcher Treibertyp benötigt wird.
-
Der
Client führt
eine Abfrage zu der Server-JSD durch, wobei die Server-JSD informiert
wird, daß eine
neue Hardwarekomponente vorliegt, und wobei Informationen über den
Drucker (beispielsweise einen Hewlett-Packard LaserJet Series III)
geliefert werden. Die Server-JSD sendet Konfigurationsinformationen
hinsichtlich des Druckers zu dem Client, der dann den richtigen
Namensraum aktualisiert. In diesem Fall werden der Geräte- und
der Schnittstellen-Namensraum in der Client-JSD aktualisiert. Durch
das Hinzufügen
eines neuen Druckers werden neue Blattknoten in den Geräte-Namensraum
und in den Schnittstellen-Namensraum eingefügt (der Schnittstelleneintrag
wird dafür
benötigt,
daß Softwareanwendungen
nach einem logischen Namen für den
Drucker, beispielsweise "Drucker
4", der dem neuen
Drucker zugeordnet ist, suchen können).
-
Zurückkehrend
zu Schritt 502 wird die Transaktion, beispielsweise das
Hinzufügen
eines neuen Druckers zu einem Client, versuchen, den richtigen Knoten
in einem Unterbaum des Client-JSD-Schemas zu sperren. Wenn der Versuch,
den richtigen Mutterknoten oder Blattknoten zu sperren, fehlschlägt, springt
die Steuerung zu einem Schritt 504. In dem Schritt 504 bestimmt
das System, ob die Transaktion eine Blockier- oder Nicht-Blockier-Transaktion
ist. Wenn die Transaktion eine Blockier-Transaktion ist, wird dieselbe
warten, bis die Sperre durch die momentane Transaktion gelöst wird.
In diesem Fall wird die Transaktion "blockieren", bis sie alle Sperren erhält, die
sie benötigt,
um fortzufahren, wobei sie dies typischerweise tun wird, bis die
gesamte Transaktion abgeschlossen ist. Beispielsweise wird die Transaktion
warten, bis sie eine Sperre auf dem Zubehörgeräte-Knoten in dem Geräte-Namensraum erhält, bevor
sie versucht, eine Sperre auf dem richtigen Knoten (beispielsweise
Drucker) in dem Schnittstellen-Namensraum zu erhalten, wenn ein neuer
Computer hinzugefügt
wird. Bei dem beschriebenen Ausführungsbeispiel
wird die Transaktion eine Sperre auf dem gewünschten Knoten erhalten, nachdem
die momentane Transaktion abgeschlossen ist, wobei zu diesem Zeitpunkt
die momentane Transaktion eine Ereignisbenachrichtigung an einen
Ereignisverwalter, der nachfolgend detaillierter beschrieben wird,
senden wird. Der Ereignisverwalter wird wiederum alle wartenden
Teilprozesse, die darauf warten, eine Sperre auf dem Unterbaum oder
einem einzelnen Eintrag zu erhalten, informieren, daß einer derselben
nun fortfahren kann.
-
Wenn
die Transaktion nicht-blockierend ist, wird sie versuchen, andere
Operationen auf anderen Teilen des Client-Schemas durchzuführen, während der
Teilprozeß,
der den gesperrten Eintrag benötigt, in
einer Warteschlange plaziert wird und warten muß, bis der Eintrag frei wird.
Typischerweise ist eine Transaktion nicht-blockierend, wenn Echtzeitbeschränkungen
existieren, wobei es effizienter ist, das Durchführen anderer Operationen fortzusetzen,
während
ein spezieller Teilprozeß wartet.
Bei dem beschriebenen Ausführungsbeispiel
ist die Blockier- oder Nicht-Blockier-Bestimmung relevant dafür, ob ein
Versuch, einen Eintrag zu sperren, fehlschlägt. Wie oben beschrieben wurde,
wartet entweder die gesamte Transaktion oder ein Teilprozeß in einer Transaktion,
bis eine Sperre erhalten wird. Wenn die Transaktion blockierend
ist, springt die Steuerung folglich zu dem Schritt 502 zurück, in dem
die Transaktion versucht, eine Sperre auf dem gewünschten Eintrag
zu erhalten, diesesmal nach dem Warten in einer Warteschlange und
einer Benachrichtigung durch einen Ereignisverwalter, wie nachfolgend
beschrieben wird. Wenn die Transaktion nicht-blockierend ist, wird
das Verfahren durchgeführt,
da dies anzeigt, daß die
Transaktion nicht auf das Erhalten einer Sperre warten will.
-
Sobald
eine Sperre auf einem gewünschten Eintrag
erhalten ist, wodurch entweder ein einzelner Eintrag oder ein Unterbaum
gesperrt wird, wird in einem Schritt 506 eine Transaktionsbezeichnung
für die
Transaktion erzeugt. Dieses Be zeichnungsobjekt ist ein eindeutiger
Identifizierer für
die spezifische Transaktion, die die Sperre bewirkte. Bei anderen
bevorzugten Ausführungsbeispielen
kann die Transaktionsbezeichnung ein beliebiger Typ eines Identifizierers
sein, der bei der Bestimmung, welche Sperren durch eine spezifische
Transaktion bewirkt wurden, brauchbar ist. Die Anwendung fährt mit
dieser Transaktionsbezeichnung fort, um Aktualisierungen auf der JSD,
spezifisch auf der Client-JSD durchzuführen. Es wird ermöglicht,
daß ein
Teilprozeß in
der Transaktion die Transaktionsbezeichnung verwendet und einen
Aufruf durchführen
kann, um eine Aktualisierung auf einem Eintrag durchzuführen oder
einen neuen Eintrag einzufügen,
beispielsweise einen Eintrag für
einen neuen Drucker unter dem Geräte-Namensraum. Bei dem beschriebenen
Ausführungsbeispiel
ist jeder Transaktion eine einzelne Transaktionsbezeichnung zugewiesen.
Dies ermöglicht,
daß das
System, wenn notwendig, bestimmt, daß eine spezielle Aktualisierung,
Modifikation oder Einfügung zu
einer speziellen Transaktion gehört.
Ein Transaktionsbezeichnungs-Objekt kann bei dem beschriebenen Ausführungsbeispiel
die Form einer einzelnen ganzen Zahl annehmen.
-
Sobald
Schritt 506 erreicht ist, ist die erste Phase, d.h. die
Sperrphase, bei der zweiphasigen Festschreibung (commit) der Sperr-API
abgeschlossen. Die Steuerung springt dann zu der zweiten Festschreibungs/Aktualisierungs-Phase,
die mit einem Schritt 508 beginnt, indem die Transaktion
die tatsächliche
Aktualisierung durchführt.
Wie vorher beschrieben wurde, kann dies eine Modifikation eines existierenden
Eintrags oder Blattknotens oder das Einfügen eines neuen Blattknotens
unter einem Unterbaum des Client-JSD-Schemas sein. Die Transaktion
bleibt bei dem Schritt 508, bis die Aktualisierung abgeschlossen
ist. Der Sperrmechanismus bestimmt, ob weitere Aktualisierungen
existieren, die als ein Teil der Transaktion durchgeführt werden
sollen. Wenn dies der Fall ist, werden die Aktualisierungen wie
oben beschrieben durchgeführt.
Dies wird für alle
Aktualisierungen in der Transaktion ausführt. Wenn die Aktualisierung
erfolgreich abge schlossen ist, springt die Steuerung zu einem Schritt 510.
-
Im
Schritt 510 wird die Aktualisierung oder werden die Aktualisierungen,
die die einzelne Transaktion bilden, die im Schritt 508 durchgeführt wird, festgeschrieben,
wobei eine Anzahl von Ereignissen stattfindet. Die Sperren, die
im Schritt 502 erlangt wurden, werden gelöst. Folglich
werden alle Einträge entsperrt.
Diese Entsperroperation schreibt die Aktualisierungen, die im Schritt 508 durchgeführt werden, fest.
Bei dem beschriebenen Ausführungsbeispiel werden
die Sperren gelöst,
indem die Transaktionsbezeichnung für jede Sperre untersucht wird.
Nur diejenigen Sperren, die die richtige Transaktionsbezeichnung
besitzen, werden gelöst,
d.h. festgeschrieben. Bei anderen bevorzugten Ausführungsbeispielen
können
andere Mechanismen zum Überprüfen der Übereinstimmung
zwischen Sperren und einer spezifischen Transaktion verwendet werden,
beispielsweise das Halten einer Tabelle von Datensätzen, wobei
jeder Datensatz eine spezifische Sperre darstellt. Sobald die Sperren
gelöst
sind, wird als Teil der Festschreibungsphase des Schritts 510 eine asynchrone
Ereignisbenachrichtigung durchgeführt, indem das Lösen der
Sperren einem zentralisierten Ereignisverwalter mitgeteilt wird.
Bei anderen bevorzugten Ausführungsbeispielen
wird eine Nachricht, daß die
Transaktion festgeschrieben wurde, zu allen Teilprozessen, die auf
die Knoten, die gesperrt waren, warten, gesendet, ohne einen Ereignisverwalter zu
durchlaufen. Bei dem beschriebenen Ausführungsbeispiel wird der Ereignisverwalter
durch einen Mutter- oder Wurzel-Knoten
eines Unterbaums in dem Client-JSD-Schema benachrichtigt, sobald
eine Sperre gelöst
wird, indem das Lösen
dem Ereignisverwalter mitgeteilt wird. Bei dem beschriebenen Ausführungsbeispiel
wartet der momentane aktive Teilprozeß, der die Sperre löst, nicht
auf eine Bestätigung
von dem Ereignisverwalter oder von irgendeinem der Teilprozesse,
die auf den Knoten, der gerade gelöst wird, warten. Bei anderen
bevorzugten Ausführungsbeispielen
können
gut bekannte synchrone Verfahren einer Ereignisbenachrichtigung verwendet
werden, um das gleiche Ergebnis zu erreichen. Alle Transak tionen,
die darauf warten, eine Sperre zu erhalten, ungeachtet dessen ob
exklusiv oder gemeinsam verwendet, registrieren sich selbst bei
dem Ereignisverwalter. Der zentrale Ereignisverwalter kann dann
bestimmen, welche Transaktionen auf den Knoten oder die Knoten,
die gelöst
wurden, warten. Sobald der Ereignisverwalter, der in 1 als
ein Fall 108 eines Eintrags 106 gezeigt ist, informiert
wird, daß Aktualisierungen
oder Einfügungen festgeschrieben
wurden, bestimmt er, welche Transaktionen zu benachrichtigen sind.
Sobald das Festschreiben durchgeführt wurde, wird die Transaktion in
einem Schritt 512 abgeschlossen.
-
Wenn,
zurückkehrend
zu Schritt 508, ein Fehlschlag stattfindet oder eine Aktualisierung
aus irgendeinem Grund nicht erfolgreich ist, springt die Steuerung
zu einem Schritt 514, in dem die Transaktion abgebrochen
wird. Dies kann beispielsweise der Fall sein, wenn ein Benutzer
einen inkompatiblen Drucker hinzufügt oder versucht, ein inkompatibles Softwareprogramm
in dem Computer zu installieren, oder versucht, ein Gerät hinzuzufügen, das
bereits mit diesem Computer verbunden ist. Dies ist detaillierter
in 6 gezeigt. Bei dieser Abbruchphase besteht das
Ziel darin, die Konfigurationsdatenbank in einen konsistenten Zustand
zurückzubringen;
d.h., in einen Zustand, der existierte, bevor die Transaktion initiiert
wurde. Wie nachfolgend detaillierter beschrieben wird, werden alle
Sperren, die sich auf die Aktualisierung beziehen, gelöst. Bei
dem beschriebenen Ausführungsbeispiel
umfaßt
diese Prozedur die Verwendung einer Ereigniswarteschlange, um Aktualisierungen,
die bereits durchgeführt
wurden, rückgängig zu
machen. Bei anderen bevorzugten Ausführungsbeispielen können andere
Mechanismen verwendet werden, um den Verlauf einer vorherigen Aktivität nachzuvollziehen,
beispielsweise eine relationale Tabelle oder einen anderen Datenbanktyp,
von dem die Aktivitätsdaten
auf eine chronologische Art und Weise gespeichert werden können.
-
Sobald
die Abbruchphase im Schritt 514 erreicht ist, wird die
Transaktion in einem Schritt 516 abgebrochen, wobei die
Konfigurationsdatenbank in einen Zustand, der vorlag, bevor die
Transaktion initiiert wurde, wiederhergestellt wird, woraufhin das Verfahren
abgeschlossen ist. An dieser Stelle und nach dem Schritt 512,
wenn die Aktualisierung erfolgreich ist, ist die zweite Phase des
Sperrverfahrens abgeschlossen, wobei das zweiphasige Festschreibungsverfahren
abgeschlossen ist.
-
6 ist
ein Flußdiagramm,
das detaillierter den Schritt 508 von 5 zeigt,
in dem die Aktualisierung gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung durchgeführt wird. Damit eine Transaktion
abgeschlossen wird, müssen
typischerweise eine oder mehrere Aktualisierungen der Konfigurationsdatenbank
durchgeführt
werden. Die Aktualisierung kann darin bestehen, den Inhalt eines
existierenden Knotens, typischerweise eines Blattknotens, zu ändern, oder
einen neuen Knoten zu einem Unterbaum hinzuzufügen. Folglich besteht der erste Schritt
darin, die tatsächliche
Aktualisierung des JSD-Schemas durchzuführen, ob es die Client- oder die
Server-JSD ist, wie in einem Schritt 602 gezeigt ist. In
einem Schritt 604 wird eine Ereigniswarteschlange für die Transaktion
erzeugt, wenn die Transaktion instantiiert (instantiated) oder erzeugt wird.
Bei dem beschriebenen Ausführungsbeispiel besitzt
jede Transaktion ihre eigene Ereigniswarteschlange. Eine Ereigniswarteschlange
kann durch eine Transaktionsbezeichnung identifiziert sein, die ebenfalls
erzeugt wird, wenn die Transaktion instantiiert wird. Bei anderen
bevorzugten Ausführungsbeispielen
müssen
die Ereigniswarteschlangen- und die Transaktions-Bezeichnung nicht
exakt erzeugt werden, wenn die Transaktion instantiiert wird, sondern zu
einem Zeitpunkt kurz danach, bevor die Aktualisierungen in dieser
Transaktion durchgeführt
werden. Eine Ereigniswarteschlange wird detaillierter nachfolgend
bezugnehmend auf 8 beschrieben. Sobald eine Ereigniswarteschlange
für die
Transaktion verfügbar
ist, werden in einem Schritt 606 alle Zustandsdaten, die
sich auf eine spezifische Aktualisierung beziehen, die notwendig
ist, um die Aktualisierung, wenn notwendig, rückgängig zu machen, als ein Eintrag
in der Ereigniswarteschlange gespeichert. Die Zustandsinformationen,
die im Schritt 606 in der Ereigniswarteschlange gespeichert
werden, spiegeln den Zustand der Konfigurationsdatenbank wieder, sobald
die Aktualisierung durchgeführt
wurde. Durch das Untersuchen der Zustandsdaten in jedem Eintrag
für eine
spezielle Transaktion wird das Netzwerk folglich exakt wissen, in
welchen Zustand die Datenbank im Fall eines Ausfalls zurückgebracht
werden soll. Indem dies inkremental für jede spezifische Aktualisierung,
die in einer Transaktion durchgeführt wird, geschieht, kann das
System die Konfigurationsdatenbank in ihren ursprünglichen
Zustand, bevor die Transaktion begonnen hat, zurückbringen. Diese Rückkehroperation
wird ferner bezugnehmend auf die 7 und 8 erklärt.
-
7 ist
ein Flußdiagramm,
das detaillierter den Schritt 514 von 5 zeigt,
in dem eine Transaktionsabbruchphase gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung gezeigt ist. In einem Schritt 702 liest
das System die Ereigniswarteschlange für die Transaktion und beginnt
damit, Operationen durchzuführen,
um die Konfigurationsdatenbank in den Zustand, der in den Ereigniswarteschlangeneinträgen beschrieben
ist, zurückzubringen.
Der oberste Eintrag in der Warteschlange, d.h. der, der zuletzt
eingetragen wurde, wird zuerst gelesen. Die Zustandsdaten in diesem
Eintrag werden untersucht, wobei Operationen auf geeigneten Knoten
in der Datenbank durchgeführt
werden, um die Datenbank in den Zustand, der in diesem Eintrag angezeigt
ist, zu bringen. Dies geschieht für jeden Eintrag in der Ereigniswarteschlange,
bis alle Aktualisierungen, die sich auf die Transaktion beziehen,
gelöscht
wurden. Bei anderen bevorzugten Ausführungsbeispielen können Datenstrukturen,
wie z.B. relationale Tabelle oder Listen, verwendet werden, um ähnliche
Zustandsdaten zu speichern und wiederzugewinnen, um die Rückkehrfunktion
zu erreichen.
-
In
einem Schritt 704 löst
das System alle Sperren, die durch die Transaktion auf beliebigen
der Knoten gehalten werden. Dies geschieht auf die gleiche Weise,
wie sie im Schritt 510 beschrieben ist. Die Sperren werden
durch die Transaktionsbezeichnung identifiziert. Sobald dieselben
identifiziert sind, weiß das
System, welche Sperren zu lösen
sind. In dem Schritt 510 wurde die Transaktionsbezeichnung
verwendet, um diejenigen Aktualisierungen zu identifizieren, die
festzuschreiben waren. Die letzte Stufe der Abbruchphase umfaßt das Benachrichtigen
des Ereignisverwalters, daß die
Sperren gelöst
wurden, wie in einem Schritt 706 gezeigt ist, so daß Teilprozesse,
die auf diese Knoten warten, auf dieselben zugreifen können. Im
Schritt 516 wird die Transaktion abgebrochen. Zu diesem
Zeitpunkt ist die Konfigurationsdatenbank in einem korrekten Zustand
und spiegelt keinerlei Aktivität
von der fehlgeschlagenen Transaktion wieder.
-
8 ist
ein Blockdiagramm, das eine Ereigniswarteschlange gemäß einem
Ausführungsbeispiel der
vorliegenden Erfindung zeigt. Eine Ereigniswarteschlange 802 ist
zweimal gezeigt, um die Aktualisierungs- und Rückkehr-Funktionen der Transaktionshandhabung
zu zeigen. Die Ereigniswarteschlange ist durch eine Transaktionsbezeichnung 804 identifiziert,
wie oben beschrieben ist. Ein Unterbaum 806 ist als durch
die Einfügung
eines neuen Knoten 808 aktualisiert dargestellt. Das Einfügen des
neuen Knotens bewirkt, daß ein
Eintrag 801 oberhalb der vorherigen Aktualisierungseinträge 812 in
die Ereigniswarteschlange 802 eingefügt wird. Wenn eine Aktualisierung
fehlschlägt,
wird eine Abbruchphase initiiert, wie bezugnehmend auf 6 beschrieben
wurde. Wenn die nächste
Aktualisierung fehlschlägt,
ist der Aktualisierungseintrag 810 beispielsweise der erste
Eintrag von der Warteschlange, der herausgenommen und verwendet
wird, um den Zustand des Unterbaums 806 umzukehren. Folglich
wird, wie bei 814 gezeigt ist, der Knoten 808,
der bei der letzten Aktualisierung eingefügt wurde, gelöscht. Dies
wird dann für
jeden der Einträge 812 von
oben nach unten durchgeführt.
Wie oben erwähnt
wurde, können
bei anderen bevorzugten Ausführungsbeispielen
andere Datenstrukturen als ein zuerst-Hinein-Zu erst-Heraus-Stapel
(FILO-Stapel; FILO = first-in, last-out) verwendet werden, um Zustandsdaten
zu speichern, die sich auf die Konfigurationsdatenbank beziehen,
beispielsweise eine verknüpfte
Liste oder eine relationale Tabelle.
-
Die
vorliegende Erfindung verwendet verschiedene Computerimplementierte
Operationen, die Daten, die in Computersystemen gespeichert sind, involvieren.
Diese Operationen umfassen diejenigen, die eine physikalische Handhabung
physikalischer Größen erfordern,
sind jedoch nicht auf diese begrenzt. Diese Größe weisen üblicherweise, obwohl es nicht
notwendig ist, die Form von elektrischen oder magnetischen Signalen
auf, die in der Lage sind, gespeichert, übertragen, kombiniert, verglichen oder
in anderer Weise gehandhabt zu werden. Die hierin beschriebenen
Operationen, die einen Teil der Erfindung bilden, sind brauchbare
Maschinenoperationen. Auf die durchgeführten Manipulationen wird oft in
Ausdrücken
wie z.B. Erzeugen, Identifizieren, Ablaufen, Bestimmen, Vergleichen,
Ausführen,
Herabladen oder Erfassen Bezug genommen. Es ist manchmal prinzipiell
aus Gründen
der üblichen
Verwendung, bequem, diese elektrischen oder magnetischen Signale
als Bits, Werte, Elemente, Variablen, Zeichen, Daten oder dergleichen
zu bezeichnen. Es sollte jedoch in Erinnerung gerufen werden, daß alle diese
und ähnliche
Ausdrücke
den zugehörigen
physikalischen Größen zuzuordnen
sind und diese nur bequeme Bezeichnungen, die für diese Größen verwendet werden, sind.
-
Die
vorliegende Erfindung bezieht sich auch auf ein Gerät, ein System
oder eine Vorrichtung zum Durchführen
der vorher genannten Operationen. Das System kann für die erforderlichen
Zwecke speziell aufgebaut sein, oder kann ein Allzweckcomputer sein,
der durch ein Computerprogramm, das in dem Computer gespeichert
ist, selektiv aktiviert oder konfiguriert wird. Die oben dargelegten
Prozesse beziehen sich nicht inhärent
auf irgendeinen speziellen Computer oder eine andere spezielle Rechenvorrichtung.
Insbesondere können
verschiedene Allzweckcomputer mit Programmen, die gemäß den hierin
gegebenen Lehren geschrieben sind, verwendet werden, wobei es alternativ
bequemer sein kann, ein spezialisierteres Computersystem aufzubauen,
um die erforderlichen Operationen durchzuführen.
-
9 ist
ein Blockdiagramm eines Allzweckcomputersystems 900, das
zum Durchführen
der Verarbeitung gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung geeignet ist. 9 zeigt
ein Ausführungsbeispiel
eines Allzweckcomputersystems. Andere Computersystem-Architekturen
und -Konfigurationen können
verwendet werden, um die Verarbeitung der vorliegenden Erfindung
durchzuführen.
Das Computersystem 900, das aus verschiedenen Untersystemen,
die nachfolgend beschrieben werden, gebildet ist, umfaßt zumindest
ein Mikroprozessoruntersystem 902 (das auch als eine Zentralverarbeitungseinheit
oder CPU bezeichnet wird). Das heißt, daß die CPU 902 durch
einen Ein-Chip-Prozessor oder durch mehrere Prozessoren implementiert
sein kann. Die CPU 902 ist ein digitaler Allzweckprozessor,
der die Operation des Computersystems 900 steuert. Unter
Verwendung von Befehlen, die aus einem Speicher wiedererlangt werden,
steuert die CPU 902 die Aufnahme und Handhabung von eingegebenen
Daten und die Ausgabe und Anzeige von Daten auf Ausgabegeräten.
-
Die
CPU 902 ist bidirektional mit einem ersten Primärspeicher 904,
typischerweise einem Direktzugriffsspeicher (RAM), und unidirektional
mit einem zweiten Primärspeicherbereich 906,
typischerweise einem Nur-Lese-Speicher (ROM), über einem Speicherbus 908 verbunden.
Wie es in der Technik gut bekannt ist, kann der Primärspeicher 904 als
ein allgemeiner Speicherbereich und als ein Notizblockspeicher verwendet
werden, wobei derselbe ferner verwendet werden kann, um eingegebene
Daten und verarbeitete Daten zu speichern. Derselbe kann auch Programmier-Befehle
und -Daten in der Form eines Mitteilungsspeichers zusätzlich zu
anderen Daten und Befehlen für
Prozesse, die die CPU 902 durchführt, speichern, und wird typischerweise
für eine schnelle Übertragung
von Daten und Befehlen auf eine bidirektionale Art und Weise über den Speicherbus 908 verwendet.
wie ebenfalls auf diesem Technikgebiet gut bekannt ist, umfaßt der Primärspeicher 906 typischerweise
elementare Operationsbefehle, einen Programmcode, Daten und Objekte,
die durch die CPU 902 verwendet werden, um ihre Funktionen durchzuführen. Die
Primärspeichervorrichtungen 904 und 906 können jedes
geeignete Computer-lesbare Speichermedium, das nachfolgend beschrieben
wird, beinhalten, abhängig
davon, ob ein Datenzugriff beispielsweise bidirektional oder unidirektional
sein muß.
Die CPU 902 kann auch direkt und sehr schnell häufig benötigte Daten
in einem Cache-Speicher 910 speichern und aus demselben
wiedergewinnen.
-
Eine
austauschbare Massenspeichervorrichtung 912 liefert eine
zusätzliche
Datenspeicherkapazität
für das
Computersystem 900 und ist entweder bidirektional oder
unidirektional über
einen peripheren Bus 914 mit der CPU 902 gekoppelt.
Beispielsweise liefert eine spezifische austauschbare Massenspeichervorrichtung,
die üblicherweise
als CD-ROM bekannt ist, Daten typischerweise unidirektional zu der
CPU 902, während
eine Diskette Daten bidirektional zu der CPU 902 leiten
kann. Der Speicher 912 kann auch ein Computerlesbares Medium aufweisen,
wie z.B. ein Magnetband, einen Flash-Speicher, Signale, die auf einer Trägerwelle verkörpert sind,
PC-Karten, tragbare Massenspeichervorrichtungen, holographische
Speichervorrichtungen und andere Speichervorrichtungen. Ein fester Massenspeicher 916 liefert
ebenfalls eine zusätzliche
Datenspeicherkapazität
und ist über
den peripheren Bus 914 bidirektional mit der CPU 902 gekoppelt.
Das üblichste
Beispiel für
den Massenspeicher 916 ist ein Festplattenlaufwerk. Im
allgemeinen ist ein Zugriff auf diese Medien langsamer als ein Zugriff
auf die Primärspeicher 904 und 906.
Die Massenspeicher 912 und 916 speichern allgemein
zusätzliche Programmierbefehle,
Daten und dergleichen, die typischerweise von der CPU 902 nicht
in aktiver Verwendung sind. Es ist offensichtlich, daß die Informationen,
die in den Massenspeichern 912 und 916 gehalten
sind, bedarfsweise in einer Standardform als Teil des Primärspeichers 904 (bei spielsweise
RAM) als virtueller Speicher enthalten sein können.
-
Zusätzlich zum
Liefern eines Zugriffs der CPU 902 auf Speicheruntersysteme
wird der periphere Bus 914 verwendet, um auch einen Zugriff
auf andere Untersysteme und Geräte
zu schaffen. Bei dem beschriebenen Ausführungsbeispiel umfassen diese
einen Anzeigemonitor 918 mit Adapter 920, eine
Druckervorrichtung 922, eine Netzwerkschnittstelle 924,
eine Hilfs-Eingabe/Ausgabe-Vorrichtungsschnittstelle 926,
eine Soundkarte 928 und Lautsprecher 930, sowie
nach Bedarf weitere Untersysteme.
-
Die
Netzwerkschnittstelle 924 ermöglicht, daß die CPU 902 mit
einem anderen Computer, einem Computernetzwerk oder einem Telekommunikationsnetzwerk
unter Verwendung einer Netzwerkverbindung gekoppelt wird, wie gezeigt
ist. Es wird in Erwägung
gezogen, daß die
CPU 902 durch die Netzwerkschnittstelle 924 während des
Durchführens
der oben beschriebenen Verfahrensschritte Informationen, beispielsweise
Datenobjekte oder Programmbefehle, von einem anderen Netzwerk empfangen kann,
oder Informationen zu einem anderen Netzwerk ausgeben kann. Informationen,
die häufig
als eine Sequenz von Befehlen, die auf einer CPU auszuführen sind,
dargestellt werden, können
von einem anderen Netzwerk beispielsweise in der Form eines Computerdatensignals,
das in einer Trägerwelle
verkörpert
ist, empfangen werden, oder zu demselben ausgegeben werden. Eine
Schnittstellenkarte oder eine gleichartige Vorrichtung und eine
zugehörige Software,
die durch die CPU 902 implementiert ist, können verwendet
werden, um das Computersystem 900 mit einem externen Netzwerk
zu verbinden und Daten in Übereinstimmung
mit Standardprotokollen zu übertragen.
Das heißt,
daß die
Verfahrensausführungsbeispiele
der vorliegenden Erfindung nur auf der CPU 902 ausgeführt werden
können,
oder über ein
Netzwerk, beispielsweise das Internet, Intranet-Netzwerke oder LAN-Netze
(LAN = local area network = lokales Netz) in Verbindung mit einer Fern-CPU
durchgeführt
werden können,
die einen Teil der Verarbeitung übernimmt.
Zusätzliche
Massenspeichervorrichtungen (nicht gezeigt) können ebenfalls durch die Netzwerkschnittstelle 924 mit
der CPU 902 verbunden sein.
-
Die
Hilfs-I/O-Vorrichtungsschnittstelle 926 stellt allgemeine
und kundenspezifische Schnittstellen dar, die ermöglichen,
daß die
CPU 902 Daten zu anderen Vorrichtungen, beispielsweise
Mikrophonen, berührungsempfindlichen
Anzeigen, Tranducerkartenlesern, Bandlesern, Stimm- und Handschrift-Erkennungsvorrichtungen,
biometrischen Lesern, Kameras, tragbaren Massenspeichervorrichtungen
und anderen Computern sendet und typischer von denselben empfängt.
-
Mit
der CPU 902 ist ferner eine Tastatursteuerung 932 über einen
lokalen Bus 934 gekoppelt, um Eingangssignale von einer
Tastatur 936 oder einer Zeigervorrichtung 938 zu
empfangen und decodierte Symbole von der Tastatur 936 oder
Zeigervorrichtung 938 zu der CPU 902 zu senden.
Die Zeigervorrichtung kann eine Maus, ein Stylus, ein Track-Ball
oder ein Tablett sein und ist zur Wechselwirkung mit einer graphischen
Benutzerschnittstelle nützlich.
-
Überdies
beziehen sich Ausführungsbeispiele
der vorliegenden Erfindung auf Computerspeicherprodukte mit einem
Computerlesbaren Medium, die einen Programmcode zum Durchführen verschiedener
Computer-implementierter Operationen enthalten. Das Computer-lesbare
Medium ist eine beliebige Datenspeichervorrichtung, die Daten speichern kann,
die danach von einem Computersystem gelesen werden. Das Medium und
der Programmcode können
solche sein, die speziell zu Zwecken der vorliegenden Erfindung
entworfen und aufgebaut sind, oder dieselben können von der Art sein, die
für Fachleute
auf dem Gebiet der Computersoftware gut bekannt sind. Beispiele
von Computer-lesbaren Medien umfassen, sind jedoch nicht auf diese
begrenzt, alle Medien, die hierin genannt sind: magnetische Medien,
wie z.B. Festplatten, Disketten und Magnetbänder; optische Medien, wie
z.B. CD-ROM-Scheiben; magneto-optische Medien, beispielsweise "Floptical Disks"; und speziell konfigurierte
Hardwarevorrichtungen, beispielsweise anwendungsspezifische integrierte
Schaltungen (ASICs), programmierbare logische Elemente (PLDs) und
ROM- und RAM-Elemente. Das Computer-lesbare Medium kann auch als
ein Datensignal, das in einer Trägerwelle
verkörpert
ist, über
ein Netzwerk von gekoppelten Computersystemen verteilt sein, so
daß der
Computer-lesbare Code auf eine verteilte Weise gespeichert und ausgeführt wird.
Beispiele eines Programmcodes umfassen sowohl einen Maschinencode,
wie er beispielsweise durch einen Compiler erzeugt wird, oder Dateien,
die einen Code höherer
Ebene enthalten, der unter Verwendung eines Interpretierers ausgeführt werden kann.
-
Es
ist für
Fachleute klar, daß die
oben beschriebenen Hardware- und Software-Elemente einen Standard-Entwurf
und einen Standard-Aufbau aufweisen. Andere Computersysteme, die
zur Verwendung mit der Erfindung geeignet sind, können zusätzliche
oder weniger Untersysteme aufweisen. Darüberhinaus sind der Speicherbus 908,
der periphere Bus 914 und der lokale Bus 934 veranschaulichend
für jegliches
Verbindungsschema, das dazu dient, die Untersysteme zu verbinden.
Beispielsweise könnte
ein lokaler Bus verwendet sein, um die CPU mit dem festen Massenspeicher 916 und
dem Anzeigeadapter 920 zu verbinden. Das Computersystem,
das in 9 gezeigt ist, ist lediglich ein Beispiel eines
Computersystems, das zur Verwendung mit der Erfindung geeignet ist.
Andere Computerarchitekturen mit unterschiedlichen Konfigurationen von
Untersystemen können
ebenfalls verwendet werden, um den Client-Computer oder den Server-Computer der
vorliegenden Erfindung zu implementieren. Bei einem anderen bevorzugten
Ausführungsbeispiel der
vorliegenden Erfindung ist der Client-Computer ein Netzwerkcomputer,
oder NC, der hinsichtlich der Funktionalität und Speicherfähigkeit
zwischen einem vollständig
unabhängigen "fetten" Client-Computer, der
als ein alleinstehender Computer wirksam sein könnte, und einem Lager-Client,
der beinahe vollständig
abhängig
von einem Server oder Großrechner
ist, angeordnet ist. Bei noch weiteren bevorzugten Ausführungsbeispielen
kann sich das Client-Sche ma auf Nicht-Computer-Vorrichtungen befinden,
beispielsweise Chipkarten oder anderen intelligenten Geräten, die
die Java-Plattform ausführen können, zusätzlich zu
Computern mit begrenztem Speicher, wie z.B. persönlichen digitalen Hilfsmitteln (PDAs;
PDA = personal digital assistants) und Handcomputern.
-
Obwohl
die vorhergehende Erfindung detailliert zu Zwecken des klareren
Verständnisses
beschrieben wurde, ist es offensichtlich, daß bestimmte Änderungen
und Modifikationen innerhalb des Schutzbereichs der beigefügten Ansprüche durchgeführt werden
können.
Beispielsweise kann die Konfigurationsdatenbank auf einer anderen
Plattform als Java basieren, beispielsweise C++. Bei einem anderen
Beispiel kann die Ereigniswarteschlange als eine Tabelle oder ein
anderer Typ eines Datendepots anstelle einer Zuerst-Hinein-Zuerst-Heraus-Stapel-Datenstruktur
implementiert sein. Bei einem weiteren Beispiel kann das zweiphasige
Sperren unter Verwendung anderer Sperrmechanismen implementiert sein,
die ein Zurückkehren
zu einem anfänglichen Zustand
ermöglichen.
Ferner sollte bemerkt werden, daß alternative Möglichkeiten
zum Implementieren sowohl des Verfahrens als auch der Vorrichtung
der vorliegenden Erfindung existieren.