DE19926116A1 - Mehr-Teilprozeß-Protokollierung in einer Konfigurationsdatenbank - Google Patents

Abstract

Ein Verfahren und eine Vorrichtung zum Erzeugen und Halten eines Protokolls von Transaktionen, die auf eine Konfigurationsdatenbank gerichtet sind, protokollieren Transaktionen in einer Konfigurationsdatenbank, indem zuerst eine Datenbanktransaktion empfangen wird, wobei die Transaktion entweder eine einzelne Modifikation, beispielsweise ein Einfügen, ein Löschen, ein Aktualisieren, oder eine Reihe von Modifikationen, die auf die Konfigurationsdatenbank gerichtet sind, ist. Ein Anfangseintrag wird in eine Protokolldatei eingefügt, wobei der Anfangseintrag einen Transaktionsidentifizierer oder eine Transaktionsbezeichnung, der oder die der Datenbanktransaktion zugeordnet ist, enthält. Nachfolgende Einträge werden in die Protokolldatei eingefügt, die spezifischen Aktualisierungen der Transaktion zugeordnet sind, wobei jeder nachfolgende Eintrag den Transaktionsidentifizierer und tatsächliche Transaktionsdaten, die sich auf die spezifische Aktualisierung beziehen, enthält. Der Protokollierungsmechanismus bestimmt dann, ob jede der spezifischen Aktualisierungen hinsichtlich der Konfigurationsdatenbank erfolgreich abgeschlossen wurde. Ein Schlußeintrag für die Transaktion wird basierend auf der Bestimmung, ob jeder der spezifischen Aktualisierungen erfolgreich abgeschlossen wurde, eingefügt.

Description

Die vorliegende Erfindung bezieht sich allgemein auf Compu­ tersoftware und Computernetzwerkanwendungen. Spezieller be­ zieht sich dieselbe auf Protokollierungs- und Erholungs-Me­ chanismen für Konfigurationsdatenbanken in Computernetzwer­ ken.

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ß die­ selben 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 Netzwerk­ softwareanwendungen, des Sendens und Empfangens von e-Mails, des Wiedererlangens und Speicherns von Informationen auf ei­ ner 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-Com­ puter relativ unabhängig sind und ihre eigenen Konfigura­ tionsinformationen 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.

Bei der herkömmlichen Netzwerkkonfiguration ist das Verfah­ ren zum Installieren neuer Software oder neuer Anwendungen ein statisches Verfahren. Bei einer solchen Konfiguration sind die Konfigurationsinformationen für jeden PC auf jeder Client-Maschine definiert. Folglich muß der Netzwerkadmini­ strator jede Konfiguration auf jedem PC statisch definieren. Bei einer herkömmlichen Computernetzwerkkonfiguration sind die Konfigurationsinformationen für jedes spezielle Unter­ system oder jeden speziellen Client in dem speziellen Client fest codiert. Außerdem erfordert bei herkömmlichen Netzwerk­ konfigurationen, die unabhängige Clients, die mit Netzwerk- Servern verbunden sind, verwenden, eine Anwendungswartung, wie z. B. das Installieren neuer Versionen oder größere Ak­ tualisierungen der Software, bei der die Aktualisierung eine Kenntnis einer oder einen Zugriff auf eine Untersystemkonfi­ guration erfordert, normalerweise, daß die Anwendung oder das Netzwerk "heruntergefahren werden", um die Wartung aus­ zuführen.

Bei herkömmlichen Computernetzwerken, die mehrere Clients und einen Server aufweisen, bei denen der Server Informatio­ nen enthält, die aus verschiedenen Gründen von einem Client benötigt werden, werden in vielen Fällen alle Daten auf dem Server, die von dem Client benötigt werden oder für densel­ ben relevant sind, von dem Server zu dem Client bewegt. Dies kann typischerweise das Bewegen großer Datenmengen beinhal­ ten, von denen viele nicht verwendet werden oder von denen viele notwendig sind, damit der Client arbeitet. Das Über­ tragen aller Daten zu dem Client ist ineffizient und erhöht den Netzwerkverkehr. Zusätzlich muß der Client ausreichend Arbeitsspeicher und Speicher aufweisen, um alle Informatio­ nen, die sich auf diesen speziellen Client beziehen, von dem Server zu speichern. Beispielsweise ist es möglich, daß Ge­ räte, wie z. B. PDAs (PDAs = personal digital assistent = persönliches digitales Hilfsmittel) und Chipkarten, die kei­ ne großen Speichermengen besitzen, in ihrem eigenen Speicher nicht alle Informationen, einschließlich Konfigurationsin­ formationen, die für dieses spezielle Gerät relevant sein könnten, enthalten können.

Bekannten Verfahren zum Protokollieren oder Verfolgen von Aktualisierungen, Modifikationen oder Einfügungen (d. h. Transaktionen), die bezüglich Konfigurationsdatenbanken durchgeführt werden, fehlen bestimmte Schlüsselmerkmale, die bei realen Netzwerken großen Ausmaßes erforderlich sind und die bei praktischen täglichen Operationen erwartet werden. Im allgemeinen besitzen Konfigurationsdatenbanken keine adä­ quaten Erholungsmechanismen, um Transaktionen oder Operatio­ nen, die bezüglich der Datenbank durchgeführt werden, und darauf bezogene Daten im Fall eines "Absturzes" oder eines anderen katastrophalen Ausfalls zu beheben. Die Daten, die in einer Konfigurationsdatenbank gespeichert sind, sind ty­ pischerweise empfindliche Daten, die im Fall eines Ausfalls, egal ob von einer einzelnen Transaktion oder der gesamten Datenbank, wiederherstellbar sein müssen. Protokollierungs­ mechanismen bekannter Konfigurationsdatenbanken besitzen ty­ pischerweise nicht die Körnung oder Robustheit, die es er­ möglichen würde, daß ein System- oder Netzwerk-Administrator ein Protokoll untersucht, um beispielsweise zu sehen, welche Operation von einem Endverbraucher die Konfigurationsdaten­ bank verfälscht oder beschädigt hat. Zusätzlich sind die Prokollierungsmechanismen für Konfigurationsdatenbanken für einen spezifischen Speichertyp oder ein beständiges Spei­ chermedium zugeschnitten, beispielsweise eine spezifische relationale Datenbank, einen speziellen Verzeichnisdienst oder einen anderen spezifischen Speichermechanismus. Dies begrenzt die Übertragbarkeit und Flexibilität der Konfigura­ tionsdatenbank und des Protokollierungsmechanismus'.

In jüngerer Zeit wurden vollständig funktionelle und zuver­ lässige Protokollierungsmechanismen notwendig, da Computer­ netzwerke hinsichtlich der Typen von Computern und der Funk­ tionalität, und speziell hinsichtlich der Anzahl von Ver­ brauchern, die bei bestimmten Netzwerken exponentiell zuge­ nommen hat, gewachsen sind. Folglich enthalten jüngere Kon­ figurationsdatenbanken große Datenmengen. Überdies sind die Informationen, die in den Konfigurationsdatenbanken enthal­ ten sind, komplexer mit der Zeit gewachsen und werden darü­ berhinaus häufiger aktualisiert als dies bei früheren Konfi­ gurationsdatenbanken, die eine wesentlich statischere Be­ schaffenheit hatten, der Fall war. Ferner besitzen die mei­ sten Protokollierungsmechanismen, die Datenbanken zugeordnet sind, die Funktion des Zurückbringens der Datenbank in einen konsistenten Zustand, was für bestimmte Zwecke adäquat ist, es jedoch für solche nicht sein kann, bei denen alle Daten wiederhergestellt werden müssen, um eine hohe Zuverlässig­ keit der Clients, beispielsweise der Netzwerkcomputer, si­ cherzustellen.

Somit wäre es erwünscht, einen Protokollierungsmechanismus für eine Konfigurationsdatenbank zu besitzen, der ein de­ tailliertes Protokoll aller Aktualisierungen und Modifika­ tionen, die hinsichtlich der Datenbank durchgeführt werden, hält. Es wäre ferner erwünscht, einen Protokollierungsme­ chanismus zu besitzen, der tatsächliche Daten enthält, die sich auf die Aktualisierungen und Modifikationen beziehen, um eine volle Wiederherstellung der Konfigurationsdatenbank im Falle eines Ausfalls zu ermöglichen. Es wäre ferner er­ wünscht, einen generischen Protokollierungsmechanismus zu besitzen, dahingehend, daß derselbe unabhängig von dem Typ des beständigen Speichers, der verwendet wird, arbeiten kann, um die Konfigurationsdatenbank zu speichern.

Die Aufgabe der vorliegenden Erfindung besteht darin, ein Verfahren, eine Vorrichtung, ein computerlesbares Medium und ein Computer-Datensignal zu schaffen, die eine flexible Pro­ tokollierung von Aktualisierungen und Modifikationen einer Konfigurationsdatenbank ermöglichen und ferner eine Erholung der Datenbank von einem Ausfall entweder einzelner Transak­ tionen oder der gesamten Datenbank ermöglichen.

Diese Aufgabe wird durch ein Verfahren nach Anspruch 1, eine Vorrichtung nach Anspruch 2, ein Computer-lesbares Medium nach Anspruch 3 und ein Computer-Datensignal nach Anspruch 4 gelöst.

Die vorliegenden Erfindung schafft ein Mehr-Teilprozeß-Pro­ tokollierungsverfahren zum Protokollieren von Transaktionen in einem Konfigurationsdatenbanksystem. Gemäß einem Aspekt der Erfindung wird eine Datenbanktransaktion, die auf die Konfigurationsdatenbank gerichtet ist, durch den Protokol­ lierungsmechanismus empfangen, wobei die Datenbanktransak­ tion eine oder mehrere spezifische Aktualisierungen, die auf die Konfigurationsdatenbank wirken, aufweist. Ein Anfangs­ eintrag wird in eine Protokolldatei eingefügt, wobei der An­ fangseintrag einen Transaktionsidentifizierer oder eine Transaktionsbezeichnung enthält, der oder die der Datenbank­ transaktion zugeordnet ist. Ein nachfolgender Eintrag wird entsprechend den spezifischen Aktualisierungen der Transak­ tion in die Protokolldatei eingefügt, wobei der nachfolgende Eintrag den Transaktionsidentifizierer und tatsächliche Transaktionsdaten, die sich auf die spezifische Aktualisie­ rung beziehen, enthält. Der Protokollierungsmechanismus be­ stimmt dann, ob jede der spezifischen Aktualisierungen hin­ sichtlich der Konfigurationsdatenbank erfolgreich abge­ schlossen wurde. Ein Schlußeintrag für die Transaktion wird auf der Bestimmung dessen, ob jede der spezifischen Aktuali­ sierungen erfolgreich abgeschlossen wurde, eingefügt.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend bezugnehmend auf die beiliegenden Zeich­ nungen näher erläutert. Es zeigen:

Fig. 1 ein Blockdiagramm, das Komponenten einer Computer­ netzwerkkonfiguration zeigt, die ein System-weites Datenschema gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigen;

Fig. 2 eine Darstellung einer n-Weg-Baumstruktur, die eine Client-Schema-Hierarchie gemäß einem Ausführungs­ beispiel der vorliegenden Erfindung darstellt;

Fig. 3 ein Blockdiagramm, das eine Struktur eines JSD-Ser­ ver-Schemas (JSD = Java-System-Datenbank) gemäß ei­ nem Ausführungsbeispiel der vorliegenden Erfindung zeigt;

Fig. 4 ein Blockdiagramm eines Systemüberblicks ein­ schließlich nachgeschalteter Komponenten eines Ser­ vers und des Protokollierungsmechanismus' in Be­ zug auf eine Beständig-Speicher-API (API = applica­ tion program interface = Anwendungsprogrammschnitt­ stelle) gemäß einem Ausführungsbeispiel der vorlie­ genden Erfindung;

Fig. 5 ein Blockdiagramm einer Klassenhierarchie eines Protokollierungsmechanismus' gemäß einem Ausfüh­ rungsbeispiel der vorliegenden Erfindung;

Fig. 6 eine schematische Darstellung eines Protokolls, das gemäß einem Ausführungsbeispiel der vorliegenden Erfindung durch den Protokollierungsmechanismus er­ zeugt und gehalten wird;

Fig. 7 ein Flußdiagramm einer Transaktion, die einen Ein­ trag in ein Protokoll erzeugt, gemäß einem Ausfüh­ rungsbeispiel der vorliegenden Erfindung;

Fig. 8 ein Flußdiagramm eines Server-Anlaufverfahrens, das zeigt, wie sich dasselbe auf den Protokollierungs­ mechanismus gemäß einem Ausführungsbeispiel der vorliegenden Erfindung bezieht; und

Fig. 9 ein Flußdiagramm eines Erholungsmechanismus' für eine Konfigurationsdatenbank gemäß einem Ausfüh­ rungsbeispiel der vorliegenden Erfindung.

Ein Konfigurationsdaten-Gerüst oder -Schema und ein Verfah­ ren zum Protokollieren und Beheben von Transaktionen, die hinsichtlich des Schemas durchgeführt werden, und Computern in einem Computernetzwerk wird bezugnehmend auf die ver­ schiedenen Zeichnungen beschrieben. Die vorliegende Erfin­ dung offenbart eine Hierarchie oder ein Datenschema zum Dar­ stellen und Speichern von Konfigurationsinformationen und darauf bezogenen Informationen in einer Systemdatenbank. Ferner wird ein Protokollierungsmechanismus offenbart, der Transaktionen, die hinsichtlich einer Konfigurationsdaten­ bank durchgeführt werden, protokolliert und eine Basis zum Beheben von Operationen bei einer Transaktion, die Daten in der Konfigurationsdatenbank aktualisieren oder modifizieren, liefert. Zu Zwecken der Darstellung eines Ausführungsbei­ spiels der vorliegenden Erfindung wird eine Java-Systemda­ tenbank (JSD) untersucht. Bei anderen bevorzugten Ausfüh­ rungsbeispielen kann die Systemdatenbank auf anderen Platt­ formtypen arbeiten. Die JSD des beschriebenen Ausführungs­ beispiels ist ein einzelnes Untersystem, das zumindest zwei Haupt-Unterkomponenten oder Unterschemata umfaßt: das Client-Schema und das Server-Schema.

Bei dem beschriebenen Ausführungsbeispiel werden Daten, die sich auf die Client-Maschine und eine Benutzerkonfiguration in einem Netzwerk beziehen, auf einem Server als Teil einer Server-JSD gespeichert. Die Konfigurationsinformationen für jeden Client, der auch als ein Untersystem bezeichnet wird, werden in dem Serverschema gespeichert. Dies steht im Kon­ trast zu herkömmlichen Netzwerken, bei denen Konfigurations­ informationen bezüglich eines Clients auf der Client-Ma­ schine fest codiert oder gespeichert sind. Das Datenschema der vorliegenden Erfindung ermöglicht, daß ein Netzwerkad­ ministrator Konfigurationsinformationen für jeden der Compu­ ter in dem Netzwerk von einem zentralen Ort aus, beispiels­ weise einem einzelnen Server, verwaltet. Folglich können al­ le Softwareaktualisierungen, Versionsaktualisierungen oder die Installation neuer Anwendungen, die eine Kenntnis einer und einen Zugriff auf eine Untersystemkonfiguration erfor­ dern, von dem zentralen Ort aus implementiert und zu den einzelnen Clients weitergeleitet werden. Benutzer auf den Client-Maschinen müssen Anwendungen nicht verlassen, wobei überdies das Netzwerk zur Wartung, um die neue Aktualisie­ rung oder Version der Anwendung zu installieren oder weiter­ zuleiten, nicht heruntergefahren werden muß.

Fig. 1 ist ein Blockdiagramm, das Komponenten einer Compu­ ternetzwerkkonfiguration, 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 be­ steht, 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.

Fig. 2 ist eine Darstellung einer n-Weg-Baumstruktur, die eine Client-Schema-Hierarchie 103 gemäß einem Ausführungs­ beispiel der vorliegenden Erfindung darstellt. Die Hierar­ chie des Client-Schema 103 und die Hierarchie des Server- Schemas 111 werden unter Verwendung eines n-Weg-Baums offen­ bart. An der Wurzel des Baums befindet sich ein Wurzelein­ trag 201, der keine Daten enthält und das einzige Knotenge­ rü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 ent­ hä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 ande­ ren bevorzugten Ausführungsbeispielen können mehr oder weni­ ger Namensräume abhängig von den Bedürfnissen einer speziel­ len Netzwerkkonfiguration existieren. Bei dem beschriebenen Ausführungsbeispiel sind die Standard-Namensräume der oberen Ebene für den JSD-Client SOFTWARE, GERÄTE, SCHNITTSTELLE, KONFIG, ALIAS und TEMP. Beispielsweise beginnt der Namens­ raum SOFTWARE an einem Knoten 205 und enthält alle Knoten und Datenverzweigungen, die sich von dem Knoten 205 verzwei­ gen. Die spezifischen Einträge in der Ebene 203 der Hierar­ chie sind Wurzeln von Unterbäumen, die die eindeutigen Na­ mensräume definieren. Alle Einträge in einem speziellen Na­ mensraum, wie z. B. SOFTWARE, sind Einträge, die sich auf Konfigurationsdaten bezüglich Softwareanwendungen für den Client 105 beziehen. Einträge in dem Datenschema der vorlie­ genden Erfindung sind aus einem eindeutigen Namen, einer Li­ ste 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 Kon­ figurationsinformationen 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 Un­ terbaum als auch der Wurzel eines Unterbaums, die abstammen­ de Einträge oder Kinder-Knoten aufweist, wirksam sein.

Wie in Fig. 2 gezeigt ist, besitzt jeder Eintrag in dem Baum eine einzelne Mutter und kann mehrere Kinder-Knoten aufwei­ sen. Ein Namensraum, wie z. B. der Namensraum SOFTWARE 209 ist ein speziell designierter Unterbaum, der Einträge ent­ hält, die sich auf Konfigurationsdaten bezüglich der Soft­ ware für einen speziellen Client, wie z. B. den Client 105, beziehen. Wie in Fig. 2 gezeigt ist, sind bei dem beschrie­ benen Ausführungsbeispiel Namensräume immer direkte Abkömm­ linge eines Wurzeleintrags 201, der auch als eine Superwur­ zel bezeichnet wird. Bei anderen bevorzugten Ausführungsbei­ spielen können Namensräume in anderen Ebenen in der Hierar­ chie 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 be­ schriebenen Ausführungsbeispiel bei allen Implementierungen der Java-Plattform verfügbar. Die sechs Namensräume sind gut bekannte Namensräume, die durch die Java-Plattform initiali­ siert werden. Andere dynamisch aufgebaute Namensräume können zu den Standard-Datenbanknamensräumen nach der Initialisie­ rung hinzugefügt werden.

Beispielsweise enthält der Namensraum SOFTWARE 209 eine Li­ ste von installierten und/oder verfügbaren Systemdiensten, beispielsweise Gerätetreibern, Benutzeranwendungen und Be­ nutzerkonfigurationsinformationen. 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 Na­ mensraum oder Eintrag ist ein Eintrag, der an einem bestän­ digen Speicherort gespeichert werden muß. Ein weiterer Typ eines Namensraums ist ein transienter Namensraum, der auf einem temporären oder flüchtigen Speicher gespeichert werden kann und nicht dauerhaft oder beständig gespeichert werden muß. Ein Beispiel von beständigen Einträgen sind Konfigura­ tionsinformationen, die sich auf Benutzerumgebungen bezie­ hen, die in einem beständigen Speicher gespeichert werden müssen. Wenn sich ein Benutzer anmeldet, muß die letzte ge­ speicherte 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 wer­ den 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 er­ laubt, daß sich ein transienter Eintrag in einem beständigen Namensraum befindet. Bei dem beschriebenen Ausführungsbei­ spiel werden beständige Einträge auf einem Fern-JSD-Server gespeichert. Bei dem beschriebenen Ausführungsbeispiel exi­ stieren unter dem Namensraum SOFTWARE vier Kategorien: An­ wendung, System, Dienst und Öffentlichkeit. Bei dem be­ schriebenen Ausführungsbeispiel unter Verwendung der Java- Plattform sind einige der Einträge in dem Namensraum SOFT­ WARE unter Verwendung von eindeutigen Java-Namensgebungskon­ ventionen angeordnet, während andere Einträge, die sich nicht auf Java beziehen, Namensgebungskonventionen basierend auf spezifischen Anwendungen aufweisen. Bei dem beschriebe­ nen 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 Informa­ tionen auseinander. Eintragsnamen unter dem Firmennamen sind firmenspezifisch.

Wie beschrieben wurde, ist der Namensraum SOFTWARE 209 der einzige Namensraum der sechs, der bei dem beschriebenen Aus­ führungsbeispiel einen beständigen Speicher aufweist. Die anderen Namensräume, wie z. B. der Namensraum GERÄT 207, be­ sitzen einen transienten Speicher. Einträge in diesen Na­ mensräumen gehen verloren, wenn der Client-Computer abge­ schaltet wird. Dies gilt bei dem beschriebenen Ausführungs­ beispiel, da die fünf transienten Namensräume Daten spei­ chern, die sich spezifisch auf einen Client-Computer bezie­ hen. Bei dem beschriebenen Ausführungsbeispiel enthält der Namensraum SOFTWARE Anwendungskonfigurationsinformationen, die gespeichert werden müssen, nachdem der Computer abge­ schaltet wird.

Unter dem Software-Namensraum befinden sich vier Kategorien: Anwendung, System, Dienst und Öffentlichkeit. Unter Verwen­ dung der Anwendungskategorie als einem Beispiel enthält ein Eintrag com.Netscape 213 den eindeutigen Firmennamen (bei­ spielsweise Netscape), wobei sich unter dem Eintrag com.Net­ scape 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äu­ fer, 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 Einga­ be/Ausgabe-Bus und/oder den peripheren Bus und/oder die Vor­ richtung, die auf dem Client vorliegen, wider. 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-Ein­ trä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 Nets­ cape Navigator, die spezifischen Daten auf der Blattknoten­ ebene anfordern will, angeordnet sind. Für eine Textverar­ beitungsanwendung würden die Blattknoteneinträge spezifische Informationen enthalten, beispielsweise Font- und Wörter­ buch-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 Ser­ ver-Schema: Maschine und Benutzer. Fig. 3 ist ein Blockdia­ gramm, das eine Struktur eines JSD-Serverschemas gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt. Das­ selbe zeigt den Server-Computer 109 und das Server-Schema 111 von Fig. 1 detaillierter. An der Spitze des n-Weg-Baums befindet sich ein Wurzeleintrag 301, der bei dem beschriebe­ nen Ausführungsbeispiel einen Namensraum CONFIG darstellt. Wie erwähnt wurde, existieren in dem Server-Schema zwei Na­ mensrä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 Aus­ führungsbeispiel aus drei Kategorien gebildet. Bei anderen bevorzugten Ausführungsbeispielen kann der Maschinennamens­ raum 303 mehr oder weniger Unterkategorien aufweisen, abhän­ gig 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 spezifi­ sche Computerhersteller beziehen, wie z. B. Sun Microsystems und IBM Corporation.

Der Protokollierungs-Mechanismus oder das -Gerüst für die oben beschriebene Konfigurationsdatenbank der vorliegenden Erfindung ist eine Mehr-Teilprozeß-Aufgabe und kann als eine Hülle oder ein Umschlag um eine Beständig-Speicher-API be­ trachtet werden. Bei dem beschriebenen Ausführungsbeispiel ist die Konfigurationsdatenbank eine JAVA-System-Datenbank, oder JSD, die allgemein zwei Seiten aufweist: eine Client- JSD und eine Server-JSD. Bei anderen bevorzugten Ausfüh­ rungsbeispielen kann die Konfigurationsdatenbank auf anderen Plattformen aufgebaut sein oder kann die Form einer herkömm­ licheren Datenbank oder Dateistruktur annehmen. Eine Bestän­ dig-Speicher-API ermöglicht, daß die Server-JSD, die oben beschrieben ist, ihre Daten in einem beständigen Speicher oder Arbeitsspeicher speichert, von dem verschiedene Typen existieren können.

Wie oben erwähnt wurde, ist der Protokollierungsmechanismus der vorliegenden Erfindung als eine Umschlagebene auf der Beständig-Speicher-API, einer Komponente des Konfigurations­ datenbanksystems, wirksam. Zurückgehend von Fig. 1, die die zwei Komponenten der JSD-Konfigurationsdatenbank des be­ schriebenen Ausführungsbeispiels (d. h. die Client-JSD und die Server-JSD) zeigt, zeigt Fig. 4 einen ähnlichen System­ überblick, der die "Ausgangsverschaltung" des Servers 109 von Fig. 1 zeigt, sowie den Protokollierungsmechanismus in Bezug auf eine Beständig-Speicher-API, gemäß einem Ausfüh­ rungsbeispiel der vorliegenden Erfindung. Mehrere der Blöcke in Fig. 4 sind, zu beschreibenden Zwecken, die gleichen wie diejenigen in den Fig. 1 bis 3. Der Client-Computer 105 ent­ hält eine Client-JSD 103, die detaillierter in Fig. 2 ge­ zeigt ist. Der Client 105 kommuniziert gemäß einem Client/Server-Protokoll 402 mit dem Servercomputer 109. Auf dem Servercomputer 109 befindet sich die Server-JSD 111, die detaillierter in Fig. 3 gezeigt ist. Eine Beständig-Spei­ cher-API 404 ist in der Verschaltung des Servers 109 ge­ zeigt. Die Beständig-Speicher-API 404 ermöglicht, daß die Server-JSD 111 die Daten in der Konfigurationsdatenbank in einem bestimmten physischen Speichermediumtyp speichert. Funktionell mit der Beständig-Speicher-API 404 verknüpft ist ein Protokollierungs-Gerüst oder -Mechanismus 406, das oder der detaillierter nachfolgend beschrieben wird. Konfigura­ tionsdaten werden in verschiedenen Typen von Medien gespei­ chert, die allgemein bei 408 gezeigt sind, beispielsweise Festplattenlaufwerken, Verzeichnisdiensten, Dateisystemen und Datenbanken.

Der Protokollierungsmechanismus 406 erzeugt Protokolldaten 410, die detaillierter nachfolgend beschrieben werden, die in einem beständigen Speicherbereich 412, der von dem be­ ständigen Speichermedium 406 getrennt ist, gespeichert wer­ den. Bei dem beschriebenen Ausführungsbeispiel werden die Protokolldaten 410 getrennt von den tatsächlichen Konfigura­ tionsdaten, die im allgemeinen in dem Speicher 408 gehalten sind, gespeichert und gehalten, wodurch die Möglichkeit des Verlusts aller Konfigurationsdaten aufgrund eines einzelnen Speicher-Speicherungsabsturzes oder -Ausfalls signifikant reduziert wird.

Fig. 5 ist ein Blockdiagramm einer Klassenhierarchie eines Protokollierungsmechanismus' gemäß einem Ausführungsbei­ spiel der vorliegenden Erfindung. Die Klassen und Unterklas­ sen, die bezugnehmend auf Fig. 5 beschrieben werden, sind abstrakte und konkrete Definitionen einer physischen Proto­ kollaufzeichnung, wie sie in einer Protokolldatei gespei­ chert wird, wobei beide in Fig. 6 gezeigt sind. Wenn der Server die Beständig-Speicher-API instantiiert, kann dersel­ be entweder eine bestimmte Klassenhierarchie liefern, oder er kann die vorgegebene Klassenhierarchie, wie sie in Fig. 5 gezeigt ist, verwenden. In jedem Fall handhabt der Server nur ein abstraktes Objekt, das nachfolgend beschrieben wird, was die Hinzufügung konkreter Objekte ermöglicht, solange dieselben der gleichen Schnittstelle oder dem gleichen Ba­ siseintrag folgen. Dieses Merkmal ist einer der Vorteile der Verwendung einer Java-Plattform. Bei anderen bevorzugten Ausführungsbeispielen können andere Objektorientierte Plattformen verwendet werden, um eine Klassenhierarchie zu definieren, um die gleichen Ergebnisse zu erreichen.

Am oberen Ende der Klassenhierarchie 502 befindet sich ein Protokoll-Aufzeichnung-Eintrag 504. Der Eintrag 504 kann auch als ein "Basiseintrag" der Klassenhierarchie 502 be­ zeichnet werden. Derselbe ist eine abstrakte Definition ei­ ner Protokollaufzeichnung und kann als eine API oder Schnittstelle des Protokollierungsgerüsts gesehen werden. Der Protokoll-Aufzeichnung-Eintrag 504 ermöglicht, daß das Protokoll unabhängig von spezifischen Speichermedien ist, da Operationen, oder Transaktionen, als abstrakte JSD-Operation gespeichert werden, im Gegensatz zu einer spezifischen Ope­ ration (beispielweise SCHREIBEN) bezüglich eines spezifi­ schen beständigen Speichers, beispielsweise einer Datei oder Datenbank. Bei einem anderen Ausführungsbeispiel bezüglich einer Erholungsprozedur (die detaillierter später erläutert wird), ist, wenn eine Erholung initiiert wird, dieselbe auf abstrakten Objekten, die durch die Protokollaufzeichnung 504 dargestellt sind, wirksam. Aus der Perspektive des Erho­ lungsmechanismus' als einem Beispiel spielt es keine Rol­ le, welcher Aufzeichnungstyp (EINFÜGEN, LÖSCHEN, AKTUALISIE­ REN usw.) behoben wird, derselbe ist auf der abstrakten De­ finition, oder dem Basiseintrag, wirksam. Die Klasse unter der Protkollaufzeichnung 504 ist eine Protokollwurzelauf­ zeichnung 506, der eine spezifische oder konkrete Darstel­ lung der Protokollaufzeichnung 504 darstellt. Derselbe defi­ niert eine interne Darstellung eines spezifischen Transak­ tionstyps. Unter der Protokollwurzelaufzeichnung 506 befin­ det sich eine Gruppe von Unterklassen, die allgemein bei 508 gezeigt ist. Spezifische Konfigurationsdatenbanktransaktio­ nen, beispielsweise LESEN, SCHREIBEN oder RÜCKGÄNGIGMACHEN wirken auf diese spezifischen Unterklassen. Bei dem be­ schriebenen Ausführungsbeispiel gibt es acht Unterklassen: Protokollanfang 510, Protokollabbruch 512, Protokoll fest­ schreiben 514, Protokoll einfügen 516, Protokoll beseitigen 518, Protokoll-Eigenschaft-Beseitigen 520 und Protokoll- Eigenschaft-Hinzufügen 522. Bei anderen bevorzugten Ausfüh­ rungsbeispielen kann sich eine kleinere oder größere Anzahl von Unterklassen unter der Protokollwurzelaufzeichnung 506 befinden. Ein spezifischer Fall, wo dies auftreten kann, ist detaillierter nachfolgend in dem Fall beschrieben, bei dem ein Server nach dem Anlaufen die vorgegebene Klassenhierar­ chie, die in Fig. 5 beschrieben ist, verwenden kann, oder eine alternative Klassenhierarchie verwenden kann.

Die spezifischen Unterklassen entsprechen den elementaren Operationen, die auf einer Konfigurationsdatenbank durchge­ führt werden können. Die Protokollanfang-Unterklasse 510 ist eine spezifische Darstellung eines Protokolleintrags, der den Beginn oder Anfang einer einzelnen Transaktion anzeigt, welche mehrere oder eine individuelle Operation oder Aktua­ lisierung enthalten kann. Dieser Eintrag wird nachfolgend detaillierter bezugnehmend auf die Fig. 6 und 7 beschrieben. Protokoll-Abbrechen 512 stellt einen Transaktions-Abbruch- Eintrag in dem Protokoll dar, der auftritt, wenn ein Fehl­ schlagen beim Durchführen einer Aktualisierung in einer Transaktion stattfindet. Das "Gegenteil" Protokoll-Abbruch 512 ist Protokoll-Festschreiben 514. Dies stellt einen Ein­ trag in dem Protokoll dar, der anzeigt, daß alle Aktualisie­ rungen, die Teil einer Transaktion waren, in der Konfigura­ tionsdatenbank erfolgreich festgeschrieben oder durchgeführt wurden. Sowohl bei Protokoll-Abbruch 512 als auch bei Proto­ koll-Festschreiben 514 werden Sperren auf Wurzelknoten oder Blattknoten in der Datenbank gelöst und alle wartenden Teil­ prozesse werden benachrichtigt. Protokoll-Einfügen 516 bzw. Protokoll-Beseitigen 518 stellen Einträge dar, die erzeugt werden, wenn ein Knoten in die Datenbank eingefügt wird (beispielsweise existiert ein neuer Benutzer- oder Client- Computer in dem Netzwerk, oder eine neue Benutzergruppe wur­ de erzeugt) bzw. wenn ein Knoten aus der Datenbank gelöscht wird. Es sei in Erinnerung gerufen, daß die Datenbank, auf die hier verwiesen wird, die Server-JSD 111 ist. Wie oben beschrieben wurde, kann ein Knoten mehrere Tupel oder Eigen­ schaften besitzen. Protokoll-Eigenschaft-Beseitigen 520 und Protokoll-Eigenschaft-Hinzufügen 522 stellen Einträge oder Operationen dar, bei denen eine Eigenschaft von einem Knoten gelöscht wird bzw. eine Eigenschaft zu einem Knoten hinzuge­ fügt wird.

Fig. 6 ist eine schematische Darstellung eines Protokolls, das durch den Protokollmechanismus gemäß einem Ausführungs­ beispiel der vorliegenden Erfindung erzeugt und gehalten wird. Bei dem beschriebenen Ausführungsbeispiel wird ein Protokoll durch eine Unix-Datei, die als Gegenstand 602 ge­ zeigt ist, dargestellt. Bei anderen bevorzugten Ausführungs­ beispielen können andere Typen von Dateien oder Datenschema­ ta zum Aufbauen der zugrundeliegenden physischen Darstellung eines Protokolls verwendet werden. Ein neues Protokoll 602 wird jedesmal erzeugt, wenn der Server 109 hochgefahren wird, und kann direkt auf einem Platten- oder Teil-System, auf das der Server zugreifen kann, jedoch getrennt von dem beständigen Speicher, der die tatsächlichen Konfigurations­ daten enthält, gespeichert werden. Ein Feld 604 enthält eine Transaktionsbezeichnung, die einer Transaktion zugewiesen wird, wenn dieselbe erzeugt wird. Bei dem beschriebenen Aus­ führungsbeispiel ist die Transaktionsbezeichnung ein eindeu­ tiger Identifizierer, der für Gruppeneinträge in dem Proto­ koll, die zu der gleichen Transaktion gehören, verwendet wird. Dies ist beispielsweise bei dem Erholungsprozeß des Protokollierungsmechanismus' nützlich.

Wie gezeigt ist, können einzelne Aktualisierungen, die zu der gleichen Transaktion gehören, unter den Protokolleinträ­ gen verstreut sein, da der Protokollierungsmechanismus ein Mehr-Teilprozeß-Verfahren ist. Das Transaktionsbezeichnungs­ feld 604 ist mit einem Operationsfeld 606 verknüpft, wie durch Pfeile 608 gezeigt ist. Das Feld 606 enthält den Ope­ rationstyp, der bei einer speziellen Aktualisierung durch­ geführt wird. Diese wurden bezüglich der Unterklassen 508 in Fig. 5 erläutert. Jeder Eintrag in dem Protokoll 602 ist ein Fall von einer der sieben Unterklassen, die in Fig. 5 ge­ zeigt sind, und ist abstrakt durch die Protokollaufzeichnung 504 definiert. Dem Feld 606 folgt ein Datenfeld 610, das die tatsächlichen Daten enthält, wenn existent, die der spezi­ fischen Operation zugeordnet sind. Für die ANFANG-Operation sind die Daten in dem Feld 610 der Name des Wurzel- oder des Mutter-Knotens des Unterbaums, auf den die Transaktion einwirken wird. Für die FESTSCHREIBEN- und ABBRUCH-Operatio­ nen existieren keine Daten in dem Feld 610, da diese Opera­ tionen primär das Lösen von Sperren auf Knoten in der Da­ tenbank nach dem Durchführen von EINFÜGUNGS- und BESEITI­ GUNGS-Operationen beinhalten.

Fig. 7 ist ein Flußdiagramm einer Transaktion, die einen Eintrag in einem Protokoll erzeugt, gemäß einem Ausführungs­ beispiel der vorliegenden Erfindung. In einem Schritt 702 initiiert ein Benutzer eine Transaktion, die auf die Konfi­ gurationsdatenbank gerichtet ist. Bei einem Beispiel unter Verwendung des beschriebenen Ausführungsbeispiels kann dies das Einfügen eines neuen Benutzers in den Benutzernamensraum 309 und unter dem Wurzeleintrag 317 der Server-JSD, wie in Fig. 3 gezeigt ist, sein. Zu diesem Zeitpunkt wird eine Transaktionsbezeichnung oder ein Identifizierer der Transak­ tion zugewiesen. In einem Schritt 704 wird ein ANFANG-Ein­ trag erzeugt und in das momentane Protokoll eingefügt, um anzuzeigen, daß eine neue Transaktion initiiert wurde, und daß derselben eines Transaktionsbezeichnung zugewiesen wur­ de. Das Datenfeld 610 kann "BENUTZER" enthalten, wenn dies der Name des Wurzelknotens ist, auf den durch die Transak­ tion eingewirkt wird. Zu diesem Zeitpunkt wurde hinsichtlich der Konfigurationsdatenbank noch nichts ausgeführt. In einem Schritt 706 wird der Aktualisierungseintrag in das Protokoll geschrieben. Beispielsweise wird ein EINFÜGEN-Eintrag mit der gleichen Transaktionsbezeichnung wie der ANFANG-Eintrag, der den Namen des Benutzers und alle anderen Informationen, die in einem BENUTZER-Knoten in dem Datenfeld 610 enthalten sind, in das Protokoll geschrieben. In einem Schritt 708 wird die Aktualisierung der Konfigurationsdatenbank durchge­ führt. Unter Verwendung des EINFÜGEN-Beispiels wird ein Kno­ ten, der den neuen Benutzer darstellt, in einen BENUTZER-Un­ terbaum (oder einen anderen geeigneten Unterbaum) der Konfi­ gurationsdatenbank eingefügt. Bei dem beschriebenen Ausfüh­ rungsbeispiel wird die Aktualisierung in dem Protokoll durchgeführt, bevor dieselbe in der Server-JSD durchgeführt wird, um in dem Fall, in dem ein Problem auftritt, nachdem die Aktualisierung in der Datenbank durchgeführt wurde, eine Erholung der Datenbank zu ermöglichen. Wenn das Protokoll zuerst aktualisiert wird, besitzt das Protokoll eine Auf­ zeichnung darüber, was durchzuführen versucht wurde, und kann die Datenbank, wenn notwendig, rekonstruieren, wenn ein Problem auftritt. Bei anderen bevorzugten Ausführungsbei­ spielen kann die Reihenfolge der Aktualisierungen des Proto­ kolls und der Datenbank variieren. Beispielsweise können Ak­ tualisierungen zuerst in der Datenbank durchgeführt werden oder können in Protokoll und Datenbank gleichzeitig durchge­ führt werden.

In einem Schritt 710 überprüft die Konfigurationsdatenbank, ob die Transaktion abgebrochen wurde. Dies kann aus ver­ schiedenen Gründen auftreten. Unter Verwendung des Benut­ zer-EINFÜGEN-Beispiels kann ein Benutzerknoten mit dem exakt gleichen Namen und Profil bereits in der Datenbank existie­ ren, wodurch ein Transaktionsabbruch bewirkt wird. Wenn dies der Fall ist, wird eine ABBRUCH-Aufzeichnung in das Proto­ koll eingegeben, wiederum mit der gleichen Transaktionsbe­ zeichnung, die ANFANG zugewiesen ist, jedoch ohne Daten in dem Datenfeld 610, woraufhin das Protokollierungsverfahren für die Transaktion abgeschlossen ist. Wenn die Transaktion nicht abgebrochen wurde, springt die Steuerung zu einem Schritt 714, in dem die Datenbank bestimmt, ob alle Aktua­ lisierungen, die für die Transaktion notwendig sind, abge­ schlossen wurden. Wenn weitere Aktualisierungen durchgeführt werden müssen, um die Transaktion abzuschließen, springt die Steuerung zu dem Schritt 706 zurück, in dem die nächste lo­ gische Aktualisierung folgend den Schritten 706 bis 710 durchgeführt wird. Wenn die Transaktion abgeschlossen ist, wird in einem Schritt 716 ein FESTSCHREIBEN-Eintrag in das Protokoll geschrieben, was anzeigt, daß eine Transaktion abgeschlossen wurde. Zu diesem Zeitpunkt ist das Verfahren des Protokollierens der Aktualisierungen, die die Transak­ tion bilden, die im Schritt 702 initiiert wurde, erledigt.

Fig. 8 ist ein Flußdiagramm eines Server-Anlaufverfahrens, das zeigt, wie sich dasselbe auf den Protokollierungsmecha­ nismus gemäß einem Ausführungsbeispiel der vorliegenden Er­ findung bezieht. Sobald ein Server, beispielsweise der Ser­ ver 111 von Fig. 1, eingeschaltet oder hochgefahren wird, werden bestimmte elementare Schritte bezüglich des Proto­ kollierungsmechanismus' durchgeführt. In einem Schritt 802 wird eine Erholungsprozedur durch das Server-Verfahren aus­ geführt, um die Datenbank in einen konsistenten Zustand zu bringen. Bei einem normalen Ausschalten des Servers wird erwartet, daß die Datenbank in einem konsistenten Zustand ist, wobei in diesem Fall die Erholungsprozedur nichts "re­ parieren" muß. Dieser Schritt ist detaillierter in Fig. 9 gezeigt. In einem Schritt 804 sichert der Server das vorhe­ rige Protokoll in einem Backup-Speicher. Die Anzahl von Backups vorheriger Protokolle, die gehalten werden, wird durch das System oder den Netzwerkadministrator bestimmt. In einem Schritt 806 erzeugt der Server ein neues Protokoll, um Einträge für die beginnende Sitzung zu halten. Bei dem be­ schriebenen Ausführungsbeispiel umfaßt dies das Erzeugen ei­ ner neuen Unix-Datei, die sich typischerweise auf einem fe­ sten Laufwerk befindet, auf die der Server zugreifen kann.

Ein Erholungsmechanismus wird verwendet, wenn der Server neu gestartet wird, um die Konfigurationsdatenbank in einen kon­ sistenten Zustand zu bringen, und muß normalerweise nur bis zu dem Punkt zurückgehen, oder das Protokoll abtasten, zu dem der Server das letzte Mal gestartet wurde. Der Erho­ lungsmechanismus kann die gesamte Konfigurationsdatenbank rekonstruieren, wenn es notwendig ist, da das Protokoll nicht nur die durchgeführte Operation, sondern auch die Da­ ten, die sich auf die Transaktion beziehen, enthält. Dies ist möglich, da das Protokoll eine Klassenhierarchie verwen­ det und die Operationen als abstrakte JSD-Operationen spei­ chert. Folglich wirkt der Erholungsmechanismus auf abstrak­ ten Objekten, d. h. der Protokollaufzeichnung 504, und ist nicht damit befaßt, von welchem Typ die Protokollaufzeich­ nung ist.

Fig. 9 ist ein Flußdiagramm eines Erholungsmechanismus' für eine Konfigurationsdatenbank gemäß einem Ausführungsbei­ spiel der vorliegenden Erfindung. In einem Schritt 902 liest der Protokollierungsmechanismus alle Einträge, die in dem momentanen Protokoll gefunden werden. In einem Schritt 904 werden alle Einträge in dem Protokoll entsprechend der Transaktionsbezeichnung kombiniert oder gruppiert. Wie oben beschrieben wurde, besitzen alle Aktualisierungen oder Ope­ rationen für die gleiche Transaktion die gleiche Transak­ tionsbezeichnung, beginnend mit der ANFANG-Operation für ei­ ne Transaktion und enden mit entweder einem FESTSCHREIBEN oder einem ABBRUCH für diese Transaktion. Alle Operationen in dieser Transaktion werden in der Reihenfolge in das Pro­ tokoll eingeführt, in der dieselben durchgeführt werden, können jedoch, und werden höchstwahrscheinlich, mit Opera­ tionen von anderen Transaktionen in der Datenbank verschach­ telt sein. In dem Schritt 904 werden alle Einträge gruppiert und kraft des Protokollierungsverfahrens nach der Transak­ tionsbezeichnung oder dem Identifizierer sortiert. In einem Schritt 906 überprüft das Protokollierungsverfahren, ob für jede Transaktion ein FESTSCHREIBEN- oder ABBRUCH-Eintrag existiert. Wenn dies der Fall ist, werden die Einträge für diese Transaktion in einem Schritt 908 beseitigt, da dies anzeigt, daß die Transaktion wirksam abgeschlossen war, und die Datenbank die Daten von dieser Transaktion richtig wi­ derspiegelt, wobei das Erholungsverfahren für diese Trans­ aktion abgeschlossen ist. Zu diesem Zeitpunkt springt die Steuerung zu dem Schritt 906 zurück, in dem die nächste Transaktion überprüft wird. Wenn für eine Transaktion ein ABBRUCH- oder FESTSCHREIBEN-Eintrag nicht gefunden wird, führt der Protokollierungsmechanismus eine "Rückgängig­ mach"-Operation bezüglich jedes der Einträge in dieser Transaktionsgruppe in einem Schritt 910 durch. Dies zeigt an, daß die Operationen für diese Transaktion nicht sinnvoll beendet wurden, weshalb die Daten, die sich auf diese Opera­ tionen beziehen, in der Konfigurationsdatenbank wahrschein­ lich nicht richtig widergespiegelt werden. Die Rückgängig­ mach-Operation kehrt im wesentlichen jede Operation, die in der Transaktion durchgeführt wird, um, oder führt eine kom­ plementäre Operation durch. Wenn folglich ein Eintrag ein EINFÜGEN eines Knotens anzeigt, der den Text "John E. Smith" enthält, wäre die komplementäre Operation ein BESEITIGEN des Knotens, wodurch der Knoten und der Text "John E. Smith" aus der Konfigurationsdatenbank gelöscht werden. Diese Rückgän­ gigmach-Operationen werden auf jedem Eintrag in der Transak­ tion durchgeführt, in der umgekehrten Reihenfolge, in der dieselben durchgeführt wurden, bis ein ANFANG-Eintrag er­ reicht wird.

Obwohl die vorhergehende Erfindung detailliert zu Zwecken eines besseren Verständnisses beschrieben wurde, ist es of­ fensichtlich, daß bestimmte Änderungen und Modifikationen innerhalb des Schutzbereichs der beigefügten Ansprüche durchgeführt werden können. Ferner sollte bemerkt werden, daß alternative Möglichkeiten zum Implementieren sowohl des Verfahrens als auch der Vorrichtung der vorliegenden Erfin­ dung existieren. Obwohl die Konfigurationsdatenbank bei­ spielsweise als eine Java-Systemdatenbank beschrieben wurde, kann dieselbe auf anderen objektorientierten Plattformen als Java implementiert werden und noch die Konzepte nutzen, die erfindungsgemäß hierin beschrieben sind.

Claims (4)

1. Mehr-Teilprozeß-Protokollierungsverfahren zum Protokol­ lieren von Transaktionen in einer Konfigurationsdaten­ bank, wobei das Verfahren folgende Schritte aufweist:
Empfangen (702) einer Datenbanktransaktion, die auf die Konfigurationsdatenbank gerichtet ist, wobei die Daten­ banktransaktion eine oder mehrere spezifische Aktuali­ sierungen, die die Konfigurationsdatenbank betreffen, aufweist;
Einfügen (704) eines Anfangseintrags, der der Daten­ banktransaktion zugeordnet ist, in eine Protokolldatei, wobei der Anfangseintrag einen Transaktionsidentifizie­ rer aufweist;
Einfügen (706) von einem oder mehreren nachfolgenden Einträgen in die Protokolldatei, entsprechend einer oder mehreren spezifischen Aktualisierungen der Konfi­ gurationsdatenbank, die der Transaktion zugeordnet sind, wobei der nachfolgende Eintrag den Transaktions­ identifizierer und Daten, die sich auf die spezifische Aktualisierung beziehen, enthält;
Bestimmen (714), ob jede der einen oder mehreren spe­ zifischen Aktualisierungen der Konfigurationsdatenbank erfolgreich abgeschlossen wurde; und
Einfügen (716) eines Schlußeintrags in die Protokoll­ datei entsprechend der Bestimmung, ob jede der einen oder mehreren spezifischen Aktualisierungen erfolgreich abgeschlossen wurde.

2. Vorrichtung zur Mehr-Teilprozeß-Protokollierung von Transaktionen in einer Konfigurationsdatenbank, wobei die Vorrichtung folgende Merkmale aufweist:
eine Transaktions-Eingabekomponente zum Empfangen (702) einer Datenbanktransaktion, die auf die Konfigurations­ datenbank gerichtet ist, wobei die Datenbanktransaktion eine oder mehrere spezifische Aktualisierungen, die die Konfigurationsdatenbank betreffen, aufweist;
eine Protokolleintrag-Komponente zum Einfügen (704) ei­ nes Anfangseintrags in eine Protokolldatei, wobei der Anfangseintrag einen Transaktionsidentifizierer auf­ weist, wobei der Anfangseintrag der Datenbanktransak­ tion zugeordnet ist, und zum Einfügen (706) von einem oder mehreren nachfolgenden Einträgen in die Protokoll­ datei, entsprechend einer oder mehreren spezifischen Aktualisierungen der Konfigurationsdatenbank, die der Datenbank zugeordnet sind, wobei der nachfolgende Ein­ trag den Transaktionsidentifizierer und Daten, die sich auf die spezifische Aktualisierung beziehen, enthält, und zum Einfügen (716) eines Schlußeintrags in die Pro­ tokolldatei entsprechend einer Bestimmung (714), ob je­ de der einen oder mehreren spezifischen Aktualisierun­ gen vollständig abgeschlossen ist; und
einen Aktualisierungsdetektor zum Bestimmen (714), ob jede der einen oder mehreren spezifischen Aktualisie­ rungen der Konfigurationsdatenbank erfolgreich abge­ schlossen wurde.

3. Computer-lesbares Medium, das Programmierbefehle ent­ hält, die angeordnet sind, um eine Mehr-Teilprozeß-Pro­ tokollierung von Transaktionen in einer Konfigurations­ datenbank durchzuführen, wobei das Computer-lesbare Me­ dium Programmierinstruktionen für folgende Schritte aufweist:
Empfangen (702) einer Datenbanktransaktion, die auf die Konfigurationsdatenbank gerichtet ist, wobei die Daten­ banktransaktion eine oder mehrere spezifische Aktuali­ sierungen, die die Konfigurationsdatenbank betreffen, aufweist;
Einfügen (704) eines anfänglichen Eintrags, der der Da­ tenbanktransaktion zugeordnet ist, in eine Protokollda­ tei, wobei der anfängliche Eintrag einen Transaktions­ identifizierer aufweist;
Einfügen (706) von einem oder mehreren nachfolgenden Einträgen in die Protokolldatei, entsprechend einer oder mehreren spezifischen Aktualisierungen der Konfi­ gurationsdatenbank, die der Transaktion zugeordnet sind, wobei der nachfolgende Eintrag den Transaktions­ identifizierer und Daten, die sich auf die spezifische Aktualisierung beziehen, enthält;
Bestimmen (714), ob jeder der einen oder mehreren spe­ zifischen Aktualisierungen der Konfigurationsdatenbank erfolgreich abgeschlossen wurde; und
Einfügen (716) eines Schlußeintrags in die Protokoll­ datei entsprechend der Bestimmung, ob jede der einen oder mehreren spezifischen Aktualisierungen erfolgreich abgeschlossen wurde.

4. Computerdatensignal, das in einer Trägerwelle verkör­ pert ist und Sequenzen von Instruktionen darstellt, die angeordnet sind, um eine Mehr-Teilprozeß-Protokollie­ rung von Transaktionen in einer Konfigurationsdatenbank durchzuführen, wobei die Sequenz von Instruktionen fol­ gende umfaßt:
Empfangen (702) einer Datenbanktransaktion, die auf die Konfigurationsdatenbank gerichtet ist, wobei die Daten­ banktransaktion eine oder mehrere spezifische Aktuali­ sierungen, die die Konfigurationsdatenbank betreffen, aufweist;
Einfügen (704) eines Anfangseintrags, der der Daten­ banktransaktion zugeordnet ist, in eine Protokolldatei, wobei der Anfangseintrag einen Transaktionsidentifizie­ rer aufweist;
Einfügen (706) von einem oder mehreren nachfolgenden Einträgen in die Protokolldatei, entsprechend einer oder mehreren spezifischen Aktualisierungen der Konfi­ gurationsdatenbank, die der Transaktion zugeordnet sind, wobei der nachfolgende Eintrag den Transaktions­ identifizierer und Daten, die sich auf die spezifische Aktualisierung beziehen, aufweist;
Bestimmen (714), ob jede der einen oder mehreren spezi­ fischen Aktualisierungen der Konfigurationsdatenbank erfolgreich abgeschlossen wurde; und
Einfügen (716) eines Schlußeintrags in die Protokoll­ datei entsprechend der Bestimmung, ob jede der einen oder mehreren spezifischen Aktualisierungen erfolgreich abgeschlossen wurde.