DE60009548T2

DE60009548T2 - Verfahren und vorrichtung um objektorientierte daten zu persistieren

Info

Publication number: DE60009548T2
Application number: DE60009548T
Authority: DE
Inventors: James Roffe; Edward Stafford
Original assignee: Unisys Corp
Current assignee: Unisys Corp
Priority date: 1999-11-19
Filing date: 2000-11-14
Publication date: 2005-02-24
Anticipated expiration: 2020-11-15
Also published as: JP2003515213A; DE60009548D1; EP1234229B1; US6411954B1; EP1234229A2; WO2001037078A3; WO2001037078A2

Description

Erfindungsgebiet
Die vorliegende Erfindung betrifft allgemein die operationale Pflege von Datenverarbeitungssystemen und insbesondere das Sichern und Wiederherstellen der Zustandsinformation.
Hintergrund
Es gibt zahlreiche Softwareapplikationen, in denen die Datenintegrität kritisch ist. Die Applikationen reichen von Flugzeug-Reservierungssystemen bis hin zu Systemen zum Steuern und Betreiben von hochintegrierten Datenverarbeitungssystemen. Der Bedarf für die Datenintegrität ist in allen Fällen größtenteils gleich. Jedoch können die Datenmenge und die Häufigkeit der Aktualisierung von Daten von Applikation zu Applikation stark variieren.
Gegenwärtig gibt es den Trend hin zur Implementierung neuer und verbesserter Softwareapplikationen mittels der Verwendung von objektorientierten Programmier-Sprachen (OOP-Sprachen). OOP-Sprachen stellen ein vorteilhaftes Mittel bereit, um grafische Benutzer-Schnittstellen zu implementieren und auch die Erweiterbarkeit der Software zu verbessern.
Objektorientierte Datenbank-Verwaltungssysteme sind für die Integration mit objektorientierten Applikationen gut geeignet und sorgen für die erforderliche Funktionalität zum Sichern und Wiederherstellen Transaktions-orientierter Daten. Jedoch kann der Sicherungs- und Wiederherstellungsvorgang in bestimmten Applikationen beschwerlich sein, wo der End-Benutzer die Fähigkeit eines robusten Datenbank-Verwaltungssystems weder braucht noch benötigt. Zusätzlich kann ein voll taugliches Datenbank-Verwaltungssystem teuer sein und signifikante Rechnerressourcen benötigen. Objektorientierte Datenbank-Verwaltungssysteme sind kaum optimal für die Verwendung in Zusammenhang mit Applikatio nen, die eine Datenintegrität benötigen, aber geringe Transaktionsraten haben. Ein objektorientiertes Informationssystem wird in der US-5 819 306 von Goldman et al. offenbart.
Ein System und Verfahren, das die zuvor erwähnten Probleme sowie andere verwandte Probleme anspricht, ist daher wünschenswert.
Zusammenfassung
Ein Verfahren und ein Gerät werden in verschiedenen Ausführungsformen bereitgestellt, um objektorientierte Daten mit reduziertem Verwaltungsaufwand persistent zu machen. Die persistente Speicherung wird für einen aktiven Datensatz und einen zweckgebundenen Datensatz errichtet. Die Bereiche für die aktiven und zweckgebundenen Datensätze werden für die Speicherung von persistenten Daten-Objekten verwendet. Nachdem ein persistentes Daten-Objekt im Computerspeicher aktualisiert ist, wird die aktualisierte Version an den aktiven Datensatz geschrieben. Dann werden die Verweise für den aktiven Datensatz und den zweckgebundenen Datensatz getauscht, wodurch der aktive Datensatz der zweckgebundene Datensatz und der zweckgebundene Datensatz der aktive Datensatz wird.
In Übereinstimmung mit einer anderen Ausführungsform der Erfindung wird ein Computerprogrammprodukt bereitgestellt, das konfiguriert ist, damit es betreibbar sein kann, um objektorientierte Daten-Objekte persistent zu machen.
Die obige Zusammenfassung der vorliegenden Erfindung ist nicht dafür vorgesehen, jede offenbarte Ausführungsform der vorliegenden Erfindung zu beschreiben. Die anschließenden Figuren und die anschließende, detaillierte Beschreibung stellen zusätzliche Beispielsausführungsformen und Aspekte der vorliegenden Erfindung bereit.
Kurze Beschreibung der Zeichnungen
Weitere Aspekte und Vorteile der Erfindung werden bei der Durchsicht der detaillierten Beschreibung und unter Bezugnahme auf die Zeichnungen ersichtlich werden, in denen:
1 eine System-Betriebskonsole darstellt, die an ein Host-Datenverarbeitungssystem gekoppelt ist;
2 ein Funktionsblockdiagramm ist, das Softwarekomponenten darstellt, die verwendet werden, um den Host 102 in Übereinstimmung mit einer Ausführungsform der Erfindung über eine Schnittstelle zu verbinden, zu betreiben und zu verwalten;
3 ein Flussdiagramm eines Prozesses zum Aktualisieren persistenter Daten in Übereinstimmung mit einer Ausführungsform der Erfindung ist;
4 ein Flussdiagramm eines Prozesses ist, das ein Startverfahren in einem Persistent-Objekt-Controller implementiert;
5A ein Flussdiagramm eines Prozesses für zweckgebundene, persistente Daten-Objekte ist;
5B einen aktuellen, persistenten Datensatz, einen Steuer-Datensatz und aktive und zweckgebundene Datensätze darstellt, wie anfänglich zum Zeitpunkt t₁, nach einer ersten Zweckbindung zum Zeitpunkt t_commit1, und nach einer zweiten Zweckbindung zum Zeitpunkt t_commit2 in Zusammenhang stehend;
6 ein Flussdiagramm eines Beispielprozesses zur Wiederherstellung persistenter Daten ist;
7 ein Objektmodelldiagramm ist, das Klassenverhältnisse zur Verwaltung persistenter Daten darstellt, und die
8A, 8B und 8C die Wechselbeziehungen zwischen persistenten Daten-Objekten, Indizes, gesicherten Indizes und gesicherten Daten persistenter Daten-Objekte darstellen.
Obwohl die Erfindung für verschiedene Modifikationen und alternative Formen zugänglich ist, wurden spezifische Ausführungsformen davon in den Zeichnungen über Beispiele gezeigt und werden hierin detailliert beschrieben. Es sollte jedoch verständlich sein, dass die detaillierte Beschreibung nicht dafür vorgesehen ist, die Erfindung auf spezielle, offenbarte Formen einzuschränken. Die Absicht der Erfindung ist es im Gegenteil, alle Modifikationen, Äquivalente und Alternativen abzudecken, die in den Geist und den Schutzumfang der Erfindung, wie in den anliegenden Ansprüchen definiert, fallen.
Detaillierte Beschreibung
Es wird angenommen, dass die vorliegende Erfindung an einer Vielfalt an objektorientierten Applikationen angewandt werden kann. Es wurde befunden, dass die Erfindung besonders passend und vorteilhaft ist, um Daten-Objekte persistent zu machen, die die Betriebe und die Konfigurationsinformation eines hochintegrierten Datenverarbeitungssystems betreffen. Obwohl die vorliegende Erfindung nicht darauf eingeschränkt ist, wird ein Verständnis der vorliegenden Erfindung mittels der Präsentation einer Ausführungsform erreicht, die eine Systembetriebskonsole und ein Host-Datenverarbeitungssystem einschließt.
1 veranschaulicht eine Systembetriebskonsole, die an ein Host-Datenverarbeitungssystem gekoppelt ist. Das Host-System 102 ist beispielsweise ein Datenverarbeitungssystem der 2200-Serie und schließt konfigurierbare Rechnerressourcen, wie beispielsweise Speicher-Untersysteme, Massenspeicher-Untersysteme, Nachrichtenkanäle und mehrere Befehlsprozessoren, ein. Die Rechnerressourcen werden für gewöhnlich vom Host-Betriebssystem (nicht gezeigt) verwaltet und sind konfiguriert, um von einem Systemoperator über die Betriebskonsole 104 verfügbar zu sein. Es wird gewürdigt sein, dass die Plattform, auf der die Betriebskonsole implementiert ist, innerhalb des Host-Gehäuses 102 errichtet oder, wie gezeigt, in einem eigenen Gehäuse implementiert sein kann.
Mittels der Betriebskonsole 104 kann ein Operator beispielsweise den Host 102 in mehrere Datenverarbeitungssysteme aufteilen, den Zugriff auf die Speicherungssysteme ermöglichen oder unwirksam machen, und die Befehlsprozessoren aktivieren oder deaktivieren. Da die Betriebskonsole 104 die verschiedenen Partitionen und die Konfigurationsinformation des Host 102 überwacht und auf einer eigenen Rechnerplattform implementiert ist, muss die Betriebskonsole sicherstellen, dass die Konfigurationsinformation zwischen einem unerwarteten Abschalten der Konsole und dem Neustarten der Konsole persistent gemacht wird.
Eine Lösung dafür, die Konfigurationsinformation in der Zeitspanne zwischen dem Ausschalten der Konsole und einem Neustart persistent zu machen, liegt in einer objektorientierten Datenbank mit zweckgebundenen Transaktionsfähigkeiten. Diese Vorgehensweise führt jedoch eine zusätzliche Betriebskomplexität für den Operator ein und erfordert auch wesentliche Rechnerressourcen von der Betriebskonsole 104. Solchermaßen wäre es für die Betriebskonsole 104 wünschenswert, die Zustandsinformation persistent zu machen, ohne zusätzliche Erhaltungsaktivitäten vom Operator zu benötigen und ohne einen bedeutsamen Anstieg der Rechnererfordernisse der Betriebskonsole 104.
2 ist ein Funktionsblockdiagramm, das die Softwarekomponenten darstellt, die verwendet werden, um den Host 102 in Übereinstimmung mit einer Ausführungsform der Erfindung über eine Schnittstelle zu verbinden, zu betreiben und zu verwalten. Die Softwarekomponenten schließen die Benutzer-Schnittstelle 122, die Betriebslogik 124, die Host-Schnittstelle 126 und den Persistent-Objekt-Controller 128 ein. Verschiedene Softwaretechnologien können verwendet werden, um die verschiedenen Komponenten zu implementieren. Zum Beispiel kann für die Benutzer-Schnittstelle 122, die Betriebslogik 124 und den Persistent-Objekt-Controller 128 eine objektorientierte Sprache geeignet sein, während für die Host-Schnittstelle 126 eine Sprache der dritten Generation, wie beispielsweise C, geeignet sein kann.
Die Benutzer-Schnittstelle 122 und die Betriebslogik 124 sorgen für die Funktion, die es dem Operator ermöglicht, die Betriebe des Hosts 102 zu verwalten. Die Benutzer-Schnittstelle 122 kann zum Beispiel als grafische Benutzer-Schnittstelle implementiert sein, und die Betriebslogik 124 schließt die Regeln ein, die den Betrieb des Systems 102 leiten. Zum Beispiel schränkt die Betriebslogik 124 den Operator bei der Konfiguration gültiger Hardwarekomponenten ein. Die Host-Schnittstelle 126 ist eine herkömmliche Software, die die Kommunikation zwischen der Betriebslogik 124 und dem Betriebssystem vom Host 102 bereitstellt.
In einer Ausführungsform wird der Persistent-Objekt-Controller 128 in C++ implementiert und verwaltet die Information, die in Bezug auf die Konfiguration des Hosts 102 persistieren muss. Zum Beispiel kann die persistente Konfigurationsinformation einschließen, welche Prozessoren, Nachrichtenkanäle, Massenspeichervorrichtungen und Eingabe/Ausgabekanäle mit welcher Partition verknüpft sind. Die Klassendefinitionen unterstützen die Erweiterbarkeit der Konfigurationsdaten, um fortzubestehen, und den Persistent-Objekt-Controller steuert und kennzeichnet, welche Daten persistent sind, und zwar gemeinsam mit der Zweckbindung von Daten an die persistente Speicherung und die Wiederherstellung der persistenten Daten, falls es erforderlich ist.
Aktualisierungen für persistente Daten, wie im Computerspeicher der Konsole 104 gespeichert, werden von der für die Daten verantwortlichen Softwarekomponente, z.B. der Betriebslogik 124, durchgeführt. Der Persistent-Objekt-Controller 128 wickelt die Zweckbindung der Aktualisierung an das Datenspeicherungselement 130 ab.
In einer Ausführungsform ist das Speicherelement 130 eine herkömmliche Magnetplatte der Art, die allgemein mit Mikrocomputern verwendet wird. Die Fachleute auf dem Gebiet werden weitere, geeignete Mittel wiedererkennen. Die Zuverlässigkeit des Speicherelements 130 ist entsprechend wie die Natur der persistenten Daten. Zum Beispiel sollte in einer Systembetriebsumgebung das Speicherelement sehr zuverlässig sein, da ein Ausfall eine weitreichende Wirkung auf die Applikationen haben könnte, die vom System 102 gekostet werden.
Der Persistent-Objekt-Controller 128 verwendet z.B. Zweckbindungs- und Wiederherstellungsverfahren, wie von der Betriebslogik 124 begonnen, um persistente Daten in einem Speicherelement 130 zu speichern und daraus wiederherzustellen. Alle persistenten Daten-Objekte werden mit dem Persistent-Objekt-Controller 128 registriert und dazu bestimmt, Teil eines persistenten Datensatzes zu sein. Nachdem eine Applikation, wie beispielsweise die Betriebslogik 124, den persistenten Datensatz aktualisiert und bestimmt hat, dass die Daten zweckgebunden werden können, wird ein Aufruf an ein Zweckbindungsverfahren getätigt, das im Persistent-Objekt-Controller 128 implementiert ist. Das Zweckbindungsverfahren schreibt den persistenten Datensatz auf den aktiven Datensatz 132 und tauscht dann den aktiven Datensatz 132 und den zweckgebundenen Datensatz 134 um. Mit anderen Worten wird der aktive Datensatz zum Zweckbindungszeitpunkt der zweckgebundene Datensatz und der zweckgebundene Datensatz der aktive Datensatz. Das Tauschen wird in einer Ausführungsform durch die Aktualisierung des Steuer-Datensatzes 136 mit neuen Verweisen für die aktiven und zweckgebundenen Datensätze erfüllt.
3 ist ein Flussdiagramm eines Verfahrens zum Aktualisieren von persistenten Daten in Übereinstimmung mit einer Ausführungsform der Erfindung. Das Verfahren wird durch die Software, z.B. die Betriebslogik 124, durchgeführt, die über persistente Daten verfügt, die mit dem Persistent-Objekt-Controller 128 registriert werden. Das Verfahren folgt allgemein einem Transaktions-ausgerichteten Verfahren zum Zweckbinden von Daten zum richtigen Zeitpunkt.
Im Schritt 162 wird von der aufrufenden Software ein Startverfahren, wie vom Persistent-Objekt-Controller 128 bereitgestellt, begonnen. Das Startverfahren verknüpft allgemein ein Transaktionsobjekt mit dem Thread der aufrufenden Software. Das Transaktionsobjekt wird verwendet, um die von der Transaktion blockierten, persistenten Daten-Objekte zu verfolgen.
Im Schritt 164 werden die persistenten Daten im Computerspeicher aktualisiert, und der Zweckbindungsvorgang des Persistent-Objekt-Controllers setzt im Schritt 166 ein. Das Zweckbindungsverfahren beinhaltet allgemein das Schreiben der aktualisierten, persistenten Daten aus dem Speicher auf den Massenspeicher und das Holen der aktiven und der zweckgebundenen Versionen der persistenten Daten.
4 ist ein Flussdiagramm eines Verfahrens, das ein Startverfahren im Persistent-Objekt-Controller 128 in Übereinstimmung mit einer Ausführungsform der Erfindung implementiert. Das Startverfahren koordiniert die Verknüpfung der Transaktionsobjekte mit den Threads, die die persistenten Daten aktualisieren. Jeder Thread, der mit dem Startverfahren beginnt, hat damit verknüpft ein Transaktionsobjekt.
Im Schritt 172 sucht das Startverfahren des Persistent-Objekt-Controllers in einer Thread-Tabelle (nicht gezeigt) nach dem Thread der aufrufenden Applikation. Die Thread-Tabelle zeigt an, welcher Thread momentan damit verknüpfte Transaktionsobjekte hat. Wenn der Thread gefunden ist, leitet der Entscheidungs schritt 174 die Steuerung an den Schritt 176, um das dazugehörige Transaktionsobjekt zu erhalten. Im Schritt 178 wird der Start-Zählwert inkrementiert, der mit dem Thread verknüpft ist. Der Start-Zählwert wird verwendet, um mittels des Threads die Anzahl der Transaktionen zu verfolgen, die persistente Daten beinhalten, die abgewickelt werden und nicht vollständig sind. Wenn ein Thread mit der Zweckbindung persistenter Daten beginnt, werden die persistenten Daten nur dann an den persistenten Speicher geschrieben, wenn es gerade keine vom Thread abgewickelte Transaktionen gibt.
Wenn der Thread der aufrufenden Applikation immer noch kein dazugehöriges Transaktionsobjekt hat, wird die Steuerung an den Schritt 180 geleitet, wo ein neues Transaktionsobjekt momentan eingeführt wird. Im Schritt 182 wird eine neue Eingabe zur Transaktionsabbildung (nicht gezeigt) hinzugefügt.
Die Transaktionsabbildung (wie im Transaktionsabbildungs-Attribut des Persistent-Controller-Objekts der 7 verkörpert) ist eine Tabelle, die den Threadbezeichner als Schlüssel und den Transaktionsobjektzeiger als Wert hat. Die Transaktionsabbildung wird verwendet, um ein Transaktionsobjekt des Threads auf einem Sperre/Entsperre-Aufruf zu finden, ohne dabei das Transaktionsobjekt im Aufruf durchlaufen zu müssen. Den Threadbezeichner erhält man vom Betriebssystem, und er wird als Schlüssel in der Transaktionsabbildung verwendet, um den Zeiger für das Transaktionsobjekt zu erhalten. Die Steuerung wird im Schritt 184 an die aufrufende Applikation zurückgeführt.
5A ist ein Flussdiagramm eines Verfahrens zum Zweckbinden von persistenten Daten-Objekten in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. Das Zweckbindungsverfahren schreibt allgemein die aktualisierten, persistenten Daten in den aktiven Datensatz 132 und aktualisiert den Steuer-Datensatz 136, damit die Verweise zwischen dem aktiven Datensatz 132 und dem zweckgebundenen Datensatz 134 getauscht werden.
Im Schritt 202 wird der Start-Zählwert für den die Zweckbindung beginnenden Applikations-Thread dekrementiert. Wenn der Start-Zählwert nicht 0 ist, leitet der Entscheidungsschritt 204 die Steuerung zum Schritt 206, um die Steuerung an die aufrufende Applikation zurückzugeben. Wenn der Thread gerade mehrere Transaktionen abwickelt, die persistente Daten mit sich bringen, werden die persistenten Daten nur dann an den Massenspeicher geschrieben, nachdem alle Transaktionen abgeschlossen sind (Start-Zählwert = 0). Im Schritt 208 werden die persistenten Daten an den aktiven Datensatz im Massenspeicher geschrieben.
Als eine hinzugefügte Datenintegritätsmaßnahme können die persistenten Daten-Objekte wahlweise redundant gespeichert werden. Das bedeutet, dass man duplizierte Versionen des aktiven Datensatzes 132 und des zweckgebundenen Datensatzes 134 erhält, wenn ein "Redundanz"-Parameter mit den persistenten Daten-Objekten verknüpft ist. Wenn solchermaßen die Redundanz bestimmt ist, leitet der Entscheidungsschritt 210 die Steuerung an den Schritt 212, wo die aktuellen, persistenten Daten an einen redundanten, aktiven Datensatz geschrieben werden. Es wird gewürdigt sein, dass das Datenspeicherungselement, auf dem die redundanten Daten gespeichert sind, abhängig vom Grad des gewünschten Datenschutzes dasselbe Datenspeicherungselement 130 oder ein getrenntes Datenspeicherungselement sein kann.
Im Schritt 214 wird der Steuer-Datensatz aktualisiert. Der Steuer-Datensatz schließt Verweise für den aktiven Datensatz 132 und den zweckgebundenen Datensatz 134 ein, die getauscht werden, nachdem der aktive Datensatz 132 geschrieben wurde. Nach dem Schritt 214 ist der frühere, aktive Datensatz der gegenwärtige, zweckgebundene Datensatz und der frühere, zweckgebundene Datensatz der gegenwärtige, aktive Datensatz. Der aktive und der zweckgebundene Datensatz werden erhalten, um die Datenintegrität für den Fall zu bewahren, dass die Konsole 104 ausfällt, während auf dem aktiven Datensatz 132 geschrieben wird.
Wenn die Redundanz bestimmt ist, leitet der Entscheidungsschritt 216 die Steuerung an den Schritt 218, wo der redundante Steuer-Datensatz aktualisiert wird. Die Verweise für den redundanten, aktiven Datensatz und den redundanten, zweckgebundenen Datensatz werden getauscht, wodurch der frühere, redundante, aktive Datensatz der gegenwärtige, redundante, zweckgebundene Datensatz und der frühere, redundante, zweckgebundene Datensatz der gegenwärtige, redundante, aktive Datensatz wird.
Im Schritt 220 wird der Steuer-Datensatz von der Konsole 104 an den Steuer-Datensatz 136 des Speicherelements 130 geschrieben. Wenn die Redundanz bestimmt ist (Entscheidungsschritt 222), wird auch der redundante Steuer-Datensatz an ein Speicherelement geschrieben (Schritt 224). Die Steuerung wird im Schritt 226 an die aufrufende Applikation zurückgegeben.
Das Verfahren zum Zweckbinden und Wiederherstellen von persistenten Daten wird vom Persistent-Objekt-Controller 128 so abgewickelt, dass die Zeiger zwischen den Objekten neu erzeugt werden können, wenn vom Speicherelement 130 eine Wiederherstellung gemacht wird. Wenn Objekte für die Persistenz registriert sind, wird ihnen ein Index zugeordnet. Wenn ein Zeiger für ein Objekt gesichert werden muss, wird stattdessen der Index gesichert. Wenn es nötig ist, Objekte vom persistenten Speicher neu zu erzeugen, werden leere Versionen aller Objekte erzeugt. Diese Objekte werden dann besetzt. Da die Zeiger wiederhergestellt werden, wird der Index verwendet, um einen Zeiger für das richtige Objekt zu erzeugen.
5B veranschaulicht einen gegenwärtigen, persistenten Datensatz, einen Steuer-Datensatz und aktive und zweckgebundene Datensätze, wie anfänglich zum Zeitpunkt t₁, nach einer ersten Zweckbindung zum Zeitpunkt t_commit1 und nach einer zweiten Zweckbindung zum Zeitpunkt t_commit2 in Zusammenhang stehend. Zum Zeitpunkt t₁ verweist der Steuer-Datensatz 136 auf den Datensatz 262 als aktiven Datensatz und auf den Datensatz 264 als zweckgebundenen Datensatz. Der aktuelle Datensatz 266 stellt die persistenten Daten als im Speicher der Konsole 104 vorliegend dar.
Zum Zeitpunkt t_commit1 wird der aktuelle, persistente Datensatz 266 an den Datensatz 262 geschrieben, der dann der zweckgebundene Datensatz wird, und der Datensatz 264 wird der aktive Datensatz. Zum Zeitpunkt t_commit2 wird der aktuelle, persistente Datensatz 266 an den Datensatz 264 geschrieben, der der zweckgebundene Datensatz wird, und der Datensatz 262 wird der aktive Datensatz.
6 ist ein Flussdiagramm eines Beispielverfahrens zur Wiederherstellung von persistenten Daten in Übereinstimmung mit einer Ausführungsform der Erfindung. Im Schritt 282 wird der Steuer-Datensatz 136 aus dem Speicherelement 130 gelesen, und im Schritt 284 wird die redundante Steuerung gelesen, wenn die Redundanz bestimmt wird.
Die in dem Steuer-Datensatz 136 und in dem redundanten Steuer-Datensatz vorhandenen Zeitstempel werden im Schritt 186 verglichen, und der zweckgebundene Datensatz, auf den durch den Steuer-Datensatz verwiesen wird, der den späteren Zeitstempel hat, wird für die Wiederherstellung ausgewählt.
Im Schritt 288 wird der im Schritt 286 ausgewählte, zweckgebundene Datensatz aus dem Speicherelement 130 gelesen, und im Schritt 290 wird der aktuelle Datensatz mittels Verwendung der Daten aus dem ausgewählten, zweckgebundenen Datensatz aktualisiert. Die Steuerung wird an die aufrufende Applikation am Schritt 292 rückgegeben.
7 ist ein Objektmodelldiagramm, das die Klassenverhältnisse zum Verwalten persistenter Daten in Übereinstimmung mit einer Ausführungsform der Erfindung darstellt. Objekte der persistenten Datenklasse erben von der seriell belegbaren Klasse. Persistente Objekte erben von einem Objekt, das die Fähigkeit für die Persistenz erlaubt. Es ist daher möglich, verschiedene Instanzen eines speziellen Objekts zu erzeugen, von denen einige persistent und einige nicht persistent sind. Die Ausführung der Registrierung eines Objekts macht es persistent, wenn die Transaktion beendet ist.
Objekte, für die die Persistenz erwünscht ist, wird erlaubt, sowohl persistente als auch nicht persistente Daten zu enthalten. Das Lade- und Speicherungsverfahren der seriell belegbaren Klasse sorgt für das Mittel zum Herstellen dieser Auswahl. Diese Verfahren stellen die Wahl der Daten und ihren Übergang an einen oder von einem seriellen Stream bereit. Die persistente Datenklasse, von der alle persistenten Objekte erben, deklariert die Ladungs- und Speicherungsverfahren (zum Sichern und Wiederherstellen der Daten) als rein virtuell. Wie im Objektmodelldiagramm gezeigt, ist es die seriell belegbare Klasse, die Lade- und Speicherungsverfahren als rein virtuell deklariert. Alle persistenten Objekte werden gezwungen, diese Verfahren zu implementieren, da sie indirekt von der seriell belegbaren Klasse erben. Die persistenten Objekte erben von der persistenten Datenklasse, die von der seriell belegbaren Klasse erbt. Da die persistente Datenklasse die Ladung und Speicherung nicht implementiert, werden alle persistenten Objekte benötigt, um dieses zu machen. Dies zwingt alle persistenten Objekte, diese Verfahren zu implementieren. Der persistente Controller wird das Laden und Speichern an den Objekten der persistenten Datenklasse aufrufen, aber die eigentliche Implementierung dieser Verfahren liegt an den Objekten, die von der persistenten Datenklasse erben.
Wenn persistente Daten wiederhergestellt werden, wird ein Vorgabekonstruktionsmittel (keine zugeführten Daten) verwendet, um jedes Objekt in der Datei zu erzeugen und dann das Ladeverfahren an jedem Objekt aufzurufen, so dass das Objekt seine Daten laden kann. Zum Zweckbinden persistenter Daten wird jedes Objekt, das während der Transaktion modifiziert wurde (gekennzeichnet, indem die Liste im Transaktionsobjekt verwendet wird), aufgerufen, um seine Daten auf den persistenten Stream festzuschreiben (Puffer, der an die persistente Datei geschrieben wird). Das aufgerufene Verfahren ist das Speicherverfahren.
Die Attribute und das Verfahren der Objekte der 7 werden im folgenden Paragraphen beschrieben.
Seriell belegbares Objekt

Lade: rein virtuelles Verfahren (in der abgeleiteten Klasse implementiert).
Speichern: rein virtuelles Verfahren (in der abgeleiteten Klasse implementiert).

Persistentes Daten-Objekt

Lese-Sperr-Zählwert – Der Zählwert der Lesevorgänge sperrt Unerledigtes. Der Lese-Sperr-Zählwert erlaubt das verschachtelte Sperren (z.B. Sperren, Sperren, Entsperren, Entsperren). Ein Zählwert > 0 sperrt das Objekt davor, von einem anderen Thread (Transaktion) verwendet zu werden.
Schreibe-Sperr-Zählwert – Der Zählwert der Schreibvorgänge sperrt Unerledigtes. Der Zählwert erlaubt das verschachtelte Sperren (z.B. Sperren, Sperren, Entsperren, Entsperren). Ein Zählwert > 0 sperrt das Objekt davor, von einem anderen Thread (Transaktion) verwendet zu werden. Wenn dieser Zählwert > 0, werden wir dieses Objekt (Aufruf des Speicherverfahrens) während der Zweckbindung schreiben.
Index: Indexwert, der diesem Objekt-Fall zugeordnet wird.
Sperren: setzt (inkrementiert) Sperr-Zählwert. Der Parameter zeigt Lesen oder Schreiben an. Wenn ein anderer Thread das Objekt gesperrt hat, dann bewirkt dies ein Warten.
Entsperren: dekrementiert den Sperr-Zählwert.
Registrieren: registriert diesen Objekt-Fall mit dem persistenten Untersystem. Dieses Verfahren erhält den Indexwert vom Objekt und sperrt das Objekt für das Schreiben.
Ent-Registrieren: ruft das persistente Untersystem auf, das Objekt als ent-registriert zu markieren und sperrt das Objekt für das Schreiben. Dem Objekt wird bei der nächsten Zweckbindung die Persistenz genommen.

Es wird gewürdigt sein, dass die Applikationsdaten, die als persistent gewünscht werden, als Objekte implementiert sind, die von der persistenten Datenklasse erben.
Persistent-Controller-Objekt

Max Index: höchster, soweit verwendeter Indexwert.
Freier Datenstapel: Vektor für befreite Indexwerte.
Trans.-Abb.: Abbildungsausführung mit Schlüssel = Thread-ID vom Betriebssystem und Wert = ein Zeiger für Transaktionsobjekt, das diesem Thread entspricht.
Objektabbildung: Abbildungsausführung mit Schlüssel = Objektindex und Wert = Struktur, die einen Zeiger für das persistente Daten-Objekt für den Index und die Dateiadresse (Offset in der Datei) enthält, wo dieses Objekt gesichert ist.
Tausche: boolesch, um anzuzeigen, welcher Puffer der aktuelle ist (zwei verwendete Speicherpuffer: aktiv und zweckgebunden).
Datei1 und Datei2: Dateiabwicklungen für die zwei persistenten Dateien (lokal und redundant).
Start: startet eine Transaktion. Wenn der Thread bereits eine Transaktion hat, inkrementiert dies den Start-Zählwert an der Transaktion. Falls nicht, dann wird ein neues Transaktionsobjekt mit einem Zählwert von 1 zugeordnet.
Zweckbindung: wenn der Start-Zählwert in der Transaktion des Threads bei dem Eintritt 1 ist, werden alle von der Transaktion aktualisierten Objekte (jene mit Schreibsperren) an den persistente Speicher geschrieben und alle Sperren freigegeben. Dekrementiert den Start-Zählwert an der Transaktion für den Thread.
Wiederherstellung: Wiederherstellt persistente Objekte aus der persistenten Datei. Dies wird beim Systemhochfahren/Initialisieren verwendet, um persistente Objekte neu zu erzeugen.

Transaktionsobjekt

Objektliste: Abbildungsausführung mit Schlüssel = Objektindex und Wert = Zeiger für das persistente Daten-Objekt für diesen Index. Dies ist eine Liste an Objekten, die durch die Transaktion gesperrt werden.
Start-Zählwert: Zählwert der durchgeführten Starts (s. persistenter Controller oben).
Start: inkrementiert Start-Zählwert.
Fertig: dekrementiert Start-Zählwert. Wenn der Zählwert auf Null geht, wird die Objektliste gelöscht.
Entferne Objekt: entfernt ein Objekt aus der Objektliste der Transaktion. Aufgerufen, da ein Entsperren erfolgte, das zu 0 zurückgelassenen Sperren führte.
Füge Objekt hinzu: fügt ein Objekt in die Objektliste der Transaktion hinzu.
Hole Start-Zählwert: gibt den Start-Zählwert zurück.

Objekt persistenter Streams

Operator ≪ streamt einen Datenwert an den persistenten Stream aus (schreibt einen Wert an den persistenten Puffer).
Operator ≫ streamt einen Datenwert aus dem persistenten Stream aus (liest einen Wert aus dem persistenten Puffer).

Die 8A, 8B und 8C veranschaulichen die Wechselbeziehungen zwischen persistenten Daten-Objekten, Indizes, gesicherten Indizes und gesicherten Daten der persistenten Objekte. 8A zeigt einen Speicher 310, der beispielhafte, persistente Daten-Objekte 312, 314 und 316 hat. Obwohl nicht gezeigt, wird man würdigen, dass jedes der persistenten Daten-Objekte 312, 314 und 316 zusätzliche Attribute einschließen kann, die auf die Daten verweisen, für die die Persistenz gewünscht wird.
Das Objekt 312 wird beispielsweise an der Speicheradresse 111111, das Objekt 314 an der Speicheradresse 333333 und das Objekt 316 an der Speicheradresse 222222 gespeichert. Jedes persistente Daten-Objekt schließt ein Attribut ein, das auf ein oder mehrere verwandte, persistente Daten-Objekte verweist. Zum Beispiel hat das Objekt 312 ein Attribut, die Speicheradresse 333333, um auf das verwandte Daten-Objekt 314 zu verweisen, und das Objekt 314 verweist an der Adresse 222222 auf das Daten-Objekt. Diese Speicher-Verweise weisen auf die Klassenverhältnisse zwischen den persistenten Daten-Objekten hin.
Jedes der persistenten Daten-Objekte 312, 314 und 316 schließt auch einen Indexwert ein, um auf einen Eintrag in der Persistent-Controller-Objektabbildung 320 der 8B zu verweisen. Jeder Eintrag in der 320 ist mit einem persistenten Daten-Objekt verknüpft und schließt die Speicheradresse des persistenten Daten-Objekts und der persistenten Speicheradresse ein, an der das persistente Daten-Objekt gespeichert wird. Die persistente Speicheradresse ist beispielsweise ein Daten-bezogenes Offset in die persistente Datendatei 322 der 8C. Das persistente Daten-Objekt an der Speicheradresse 333333 wird am Offset 32 in der Datei 322 gespeichert, das persistente Daten-Objekt an der Speicheradresse 222222 wird am Offset 47 in der Datei 322 gespeichert, und das persistente Daten-Objekt an der Speicheradresse 111111 wird am Offset 60 in der Datei 322 gespeichert.
Jedes persistente Daten-Objekt, das in der Datei 322 gespeichert ist, schließt seinen dazugehörigen Index zusammen mit Attributwerten ein, die auf die verwandten, persistenten Daten-Objekte verweisen (wenn es verwandte Daten-Objekte gibt). Zum Beispiel hat das persistente Daten-Objekt von der Speicheradresse 111111 den Indexwert 5 und wird am Offset 60 gespeichert. Das persistente Daten-Objekt 324 am Offset 60 schließt zwei Attribute ein. Das erste Attribut ist der Indexwert 5, der mit dem persistenten Daten-Objekt verknüpft ist, und das zweite Attribut verweist auf den Index eines verwandten, persistenten Daten-Objekts. Zum Beispiel ist der Attributwert 2 das Indexattribut des persistenten Daten-Objekts 314, auf das durch das Daten-Objekt 314 gezeigt wird. Auf ähnliche Weise wird das Daten-Objekt 326, das am Dateioffset 32 gespeichert ist und den Indexwert 2 hat, mit dem persistenten Daten-Objekt 314 verknüpft und hat einen Attributwert 4, der auf den Index des persistenten Daten-Objekts 316 verweist. Da das Objekt 316 keine verwandten Objekte hat, gibt es einen Attributwert. Das Speichern der Indizes der verwandten, persistenten Daten-Objekte sorgt für die wirkungsvolle Rekonstruktion des Objektverhältnisses, wenn die Daten aus der persistenten Datendatei 322 wiederhergestellt werden.
Entsprechend stellt die vorliegende Erfindung, inmitten weiterer Aspekte, ein Verfahren bereit, um Daten-Objekte persistent zu machen, ohne sich das Verwaltungsaufwand eines Objektorientierten Datenbank-Verwaltungssystem zuziehen zu müssen. Weitere Aspekte und Ausführungsformen der vorliegenden Erfindung werden den Fachleuten auf dem Gebiet aus der Betrachtung der Beschreibung und der praktischen Anwendung der hierin offenbarten Erfindung ersichtlich. Es ist beabsichtigt, dass die Beschreibung und die dargestellten Ausführungsformen nur als Beispiele betrachtet werden, wobei der Schutzumfang der Erfindung durch die folgenden Ansprüche angegeben wird.
Wenn technische Merkmale in den Ansprüchen mit Bezugszeichen versehen sind, so sind diese Bezugszeichen lediglich zum besseren Verständnis der Ansprüche vorhanden. Dementsprechend stellen solche Bezugszeichen keine Einschränkungen des Schutzumfangs solcher Elemente dar, die nur exemplarisch durch solche Bezugszeichen gekennzeichnet sind.

Claims

Ein Computer-implementiertes Verfahren, um objektorientierte Daten persistent zu machen, das folgendes umfasst: das Errichten eines persistenten Speichers (130) für einen aktiven Datensatz (132) und einen zweckgebundenen Datensatz (134) einer objektorientierten Datenbank; das Aktualisieren von aktuellen Daten-Objekten (266) im Computerspeicher; das Schreiben der aktuellen Daten-Objekte (266) an den aktiven Datensatz (132), und das Tauschen von Verweisen für den aktiven Datensatz (132) und den zweckgebundenen Datensatz (134), wodurch der aktive Datensatz (132) der zweckgebundene Datensatz (134) und der zweckgebundene Datensatz (134) der aktive Datensatz (132) wird.
Das Verfahren nach Anspruch 1, das weiterhin das Schreiben eines Steuer-Datensatzes (136) in den persistenten Speicher (130) umfasst, der auf den aktiven Datensatz (132) und den zweckgebundenen Datensatz (134) verweist.
Das Verfahren nach Anspruch 1, das weiterhin das Wiederherstellen von Daten mittels Verwendung von Daten aus dem zweckgebundenen Datensatz (134) umfasst.
Das Verfahren nach Anspruch 1, das weiterhin folgendes umfasst: das Errichten von persistentem Speicher (130) für einen redundanten, aktiven Datensatz und einen redundanten, zweckgebundenen Datensatz; das Schreiben der aktuellen Daten-Objekte (266) an den redundanten, aktiven Datensatz; das Tauschen der Verweise an den redundanten, aktiven Datensatz und den zweckgebundenen, redundanten Datensatz, wodurch der redundante, aktive Datensatz der redundante, zweckgebundene Datensatz und der redundante, zweckgebundene Datensatz der redundante, aktive Datensatz wird.
Das Verfahren nach Anspruch 4, das weiterhin folgendes umfasst: das Schreiben eines ersten Steuer-Datensatzes (136), der auf den aktiven Datensatz (132) und den zweckgebundenen Datensatz (134) verweist, an den persistenten Speicher (130), und das Schreiben eines zweiten Steuer-Datensatzes, der auf den redundanten, aktiven Datensatz und den redundanten, zweckgebundenen Datensatz verweist, an den persistenten Speicher (130).
Das Verfahren nach Anspruch 5, das weiterhin das Schreiben von jeweiligen Zeitstempeln an den ersten (136) und den zweiten Steuer-Datensatz umfasst.
Das Verfahren nach Anspruch 6, das weiterhin folgendes umfasst: das Vergleichen von Zeitsptempeln des ersten Steuer-Datensatzes (136) und des zweiten Steuer-Datensatzes; das Widerherstellen von Daten vom zweckgebundenen Datensatz (134) auf die aktuellen Daten-Objekte (266), wenn der erste Steuer-Datensatz (136) einen früheren Zeitstempel als der zweite Steuer-Datensatz hat, und das Wiederherstellen von Daten vom redundanten, zweckgebundenen Datensatz auf die aktuellen Daten-Objekte (266), wenn der zweite Steuer-Datensatz einen früheren Zeitstempel als der erste Steuer-Datensatz (136) hat.
Das Verfahren nach den Ansprüchen 1 oder 7, das weiterhin folgendes umfasst: das Instantiieren eines persistenten Controller-Objekts und das Registrieren der Daten-Objekte (312, 314, 316) für die persistente Speicherung mit dem persistenten Controller-Objekt.
Das Verfahren nach Anspruch 8, das weiterhin das Erzeu- gen einer persistenten Objekt-Abbildung (320) umfasst, die Einträge hat, die jeweils mit den Daten-Objekten (312, 314, 316) verknüpft sind, die mit dem persistenten Controller-Objekt registriert sind, wobei die persistente Objekt-Abbildung (320) Speicheradresszeiger hat, die mit den registrierten Daten-Objekten (312, 314, 316) verknüpft sind.
Das Verfahren nach Anspruch 9, worin jedes registrierte Daten-Objekt (312, 314, 316) einen dazugehörigen Index einschließt, der auf einen Eintrag in die persistente Objekt-Abbildung (320) verweist.
Das Verfahren nach Anspruch 10, worin jeder Eintrag in die persistente Objekt-Abbildung (320) weiterhin einen Verweis für eine persistente Speicheradresse einschließt, an der das persistente Daten-Objekt (312, 314, 316) gespeichert wird.
Das Verfahren nach Anspruch 11, das weiterhin folgendes umfasst: das Schreiben des dazugehörigen Index eines jeden persistenten Daten-Objekts (312, 314, 316) an den persistenten Speicher und das Assoziieren im persistenten Speicher, mit den Indizes der persistenten Daten-Objekte (312, 314, 316), von Indizes von einem oder mehreren persistenten Daten-Objekten (312, 314, 316), die durch eine Klasse verwandt sind.
Ein Gerät, um objektorientierte Daten persistent zu machen, das folgendes umfasst: ein Mittel (130) zum Errichten eines persistenten Speichers für einen aktiven Datensatz (132) und einen zweckgebundenen Datensatz (134) einer objektorientierten Datenbank; ein Mittel (124) zum Aktualisieren von aktuellen Daten-Objekten (266) im Computerspeicher; ein Mittel (128) zum Schreiben der aktuellen Daten-Objekte (266) an den aktiven Datensatz (132), und ein Mittel (128) zum Tauschen von Verweisen für den aktiven Datensatz (132) und den zweckgebundenen Datensatz (134), wodurch der aktive Datensatz (132) der zweckgebundene Datensatz (134) und der zweckgebundene Datensatz (134) der aktive Datensatz (132) wird.
Das Gerät nach Anspruch 13, das weiterhin ein Mittel (128) zum Wiederherstellen der Daten mittels Verwendung der Daten aus dem zweckgebundenen Datensatz (134) umfasst.
Das Gerät nach Anspruch 14, das weiterhin folgendes umfasst: ein Mittel zum Errichten des persistenten Speichers für einen redundanten, aktiven Datensatz und einen redundanten, zweckgebundenen Datensatz; ein Mittel zum Schreiben der aktuellen Daten-Objekte an den redundanten, aktiven Datensatz, und ein Mittel zum Tauschen der Verweise für den redundanten, aktiven Datensatz und den zweckgebundenen, redundanten Datensatz, wodurch der redundante, aktive Datensatz der redundante, zweckgebundene Datensatz und der redundante, zweckgebundene Datensatz der redundante, aktive Datensatz wird.