DE69032389T2

DE69032389T2 - Prozess und Gerät zur Erhaltung der Datenintegrität einer Datenbank

Info

Publication number: DE69032389T2
Application number: DE69032389T
Authority: DE
Inventors: Robert Abraham; Richard Smith Briggs; Richard Eugene Moore; William Lawrence Rich; Cynthia A Ross; Floyd Shackelford; John Russel Tiller
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1989-10-23
Filing date: 1990-09-21
Publication date: 1999-02-18
Anticipated expiration: 2010-09-22
Also published as: JPH03138735A; EP0425415A2; EP0425415A3; JPH0833863B2; DE69032389D1; US5313629A; EP0425415B1

Description

Diese Erfindung bezieht sich auf Datenbankverwaltungssysteme und insbesondere auf ein Verfahren und ein Gerät zur Erhaltung der Datenintegrität der Datenbank.
Computerbasierte Datenbankverwaltungssysteme werden weithin benutzt, um große Mengen verknüpfter Daten zu speichern und zu handhaben. Datenbankverwaltungssysteme können mittels eines Computerprogramms, das Datenbankverwaltungsprogramm oder Datenbankmanager genannt wird, in einem Personalcomputer, einem Minicomputer oder Mainframe-Computer implementiert werden. Obwohl viele Datenbankverwaltungssysteme mittels konventioneller Programmiertechniken implementiert werden, wurden Datenbankverwaltungssysteme nach dem Stand der Technik entwickelt und beginnen nun kommerziell aufzutreten, indem sie objektorientierte Programmierungssysteme und -prozesse benutzen.
Objektorientierte Programmierungssysteme und Prozesse waren Gegenstand von vielen Untersuchungen und von Interesse in Datenverarbeitungsumgebungen nach dem Stand der Technik. Die objektorientierte Programmierung ist ein Computerprogramm mit Pakkungstechnik, das wiederverwendbare und einfach erweiterbare Programme bereitstellt. Im Gegensatz zu bekannten funktionellen Programmierungstechniken, die nicht einfach an neue funktionelle Anforderungen und neue Datentypen angepaßt werden können, sind objektorientierte Programme wiederverwendbar und erweiterbar, sobald neue Anforderungen auftreten. Mit immer mehr zunehmender Komplexität von computerbasierten Systemen kam der objektorientierten Programmierung immer mehr Beachtung zu und war Anlaß von Untersuchungen.
In einem objektorientierten Programmierungssystem liegt der Schwerpunkt eher auf Daten als auf Funktionen. Objektorientierte Programmierungssysteme bestehen aus einer großen Anzahl von "Objekten". Ein Objekt besteht aus einer Datenstruktur und einem Satz mit Operationen oder Funktionen, die auf die Datenstruktur zugreifen können. Die Datenstruktur kann als "Rahmen" dargestellt werden. Der Rahmen hat viele "Schlitze", von denen jeder ein "Attribut" mit Daten enthält. Das Attribut kann einfach sein (d. h. eine Ganzzahl oder eine Kette) oder eine Objektreferenz, die ein Zeiger auf ein anderes Objekt oder andere Objekte (nachstehend definiert) ist. Jede Operation (Funktion), die auf die Datenstruktur zugreifen kann, wird "Verfahren" genannt.
Fig. 1 zeigt eine schematische Darstellung eines Objekts, in dem ein Rahmen in seinen Verfahren eingekapselt ist. Fig. 2 zeigt das Beispiel eines Objekts, in dem sich die Datenstruktur auf Personaldaten und eine Anzahl von Verfahren bezieht, welche diese Datenstruktur umgeben. Ein Verfahren enthält beispielsweise das Alter eines Mitarbeiters. Jedes definierte Objekt wird gewöhnlich in einer Anzahl von "Objekten" erscheinen. Jedes Objekt enthält die besondere Datenstruktur für ein besonderes Objektbeispiel. Ein Objekt für die Angestellte namens Joyce Smith ist beispielsweise ein Objekt des "Personal" Objekts.
Die objektorientierten Programmierungssysteme liefern zwei primäre Charakteristiken, mit denen flexible und wiederverwendbare Programme entwickelt werden können. Diese Charakteristiken werden als "Kapselung" und "Vererbung" bezeichnet. Wie aus Fig. 1 ersichtlich ist, wird der Rahmen durch seine Verfahren (Funktionen) eingekapselt. Um jeden Datenteil wurde eine Codewand errichtet. Der Zugriff auf den Rahmen erfolgt über Einschließungsverfahren. Dadurch wird für Datenunabhängigkeit gesorgt, weil auf die Datenstruktur eines Objekts nur über seine Verfahren zugegriffen wird. Nur die zugehörigen Verfahren kennen die interne Datenstruktur. Dies sorgt für Datenintegrität.
Die "Vererbungs"-Eigenschaft der objektorientierten Programmierungssysteme ermöglicht es, daß zuvor geschriebene Programme erweitert werden können, indem neue Ober- und Unterklassen mit Objekten erstellt werden. Neue Objekte werden dadurch beschrieben, wie sie sich von vorher existierenden Objekten unterscheiden, so daß ganz neue Programme nicht geschrieben werden müssen, um die neuen Daten- oder Funktionstypen zu verarbeiten.
Fig. 3 zeigt die Vererbungseigenschaft. Zur Vereinfachung der Abbildung sind die Objekte in Rechtecken anstatt in Kreisen dargestellt, wobei der Objektname im Rechteck oben steht, der Rahmen unter dem Objektnamen angeordnet ist, und die Verfahren unter dem Rahmen angeordnet sind. Es wird nun auf Fig. 3 Bezug genommen, die drei Objektklassen für "Verkäufer", "Angestellter" und "Person" zeigt, wobei ein Verkäufer eine "Art" Angestellter ist" der eine "Art" Person ist. Anders ausgedrückt, ist der Verkäufer eine Unterklasse des Angestellten, und der Angestellte ist die Oberklasse des Verkäufers. Ebenso ist der Angestellte die Unterklasse der Person, und die Person ist die Oberklasse des Angestellten. Jede abgebildete Klasse enthält drei Objekte. B. Soutter, W. Tipp und B. G. Blue sind Verkäufer. B. Abraham, K. Yates und R. Moore sind Angestellte. J. McEnro, R. Nader und R. Reagan sind Personen. Anders ausgedrückt ein Objekt wird mittels einer "is a" Relation mit seiner Klasse verbunden.
Jede Unterklasse "vererbt" den Rahmen und die Verfahren von seiner Oberklasse. So vererbt beispielsweise ein Verkäufer sein Alter und Mietdatenobjekte sowie Beförderungsverfahren von der Angestelltenoberklasse. Der Verkäufer enthält auch ein einzigartiges Quotenattribut und ein Provisionszahlverfahren. Jedes Objekt kann auf alle Verfahren und Rahmen seiner Oberklasse zugreifen, so daß beispielsweise B. G. Blue befördert werden kann.
In einem objektorientierten System fordert eine High-Level-Routine ein Objekt an, um eines seiner Verfahren durchzuführen, indem dem Objekt eine "Nachricht" gesendet wird, die dem Objekt sagt, was zu tun ist. Das Empfängerobjekt beantwortet die Nachricht durch Auswahl des Verfahrens, das den Nachrichtenname implementiert, dieses Verfahren ausführt und dann die Steuerung zusammen mit den Ergebnissen des Verfahrens an die aufrufende High-Level-Routine zurückgibt.
Objektorientierte Programmierungssysteme können wie Datenbankverwaltungssysteme benutzt werden, die in der Lage sind, in einer großen Datenbank zu arbeiten und erweiterbar und anpassungsfähig sind. In einem objektorientierten Datenbankverwaltungssystem werden die Daten in der Datenbank organisiert und als Objekte mit den Beispielen der Objekte eingekapselt, welche die Daten in der Datenbank sind. Ebenso kann der Datenbankmanager als ein Objektsatz mit Datenbankverwaltungsoperationen organisiert werden, die durchgeführt werden, indem Nachrichten von einem Objekt zum anderen gesendet werden. Das Zielobjekt führt die verlangte Aktion mittels seiner Verfahren mit seinen Attributen durch.
Gleich ob ein Datenbankverwaltungssystem mittels objektorientierter Programmierung oder konventioneller Programmierung durchgeführt wird, ein Hauptanliegen eines Datenbankverwaltungssystems ist die Erhaltung der Datenintegrität. Die Erhaltung der Datenintegrität wird in dem Maße schwierig, wie Größe und Komplexität von Daten zunehmen. Bei einer sehr großen Datenbank ist es außerdem wünschenswert, daß mehrere Aufgaben gleichzeitig durchgeführt werden müssen, wodurch die Datenintegrität weiter beeinträchtigt wird.
Insbesondere steuert ein Datenbankmanager normalerweise die Durchführung von Aufgaben in Daten in der Datenbank. Jede Aufgabe besteht aus einer Anzahl von Schritten, wobei jeder Schritt in der Änderung von Daten in der Datenbank resultieren kann. Die Datenintegrität geht verloren, wenn eine Aufgabe vor Beendigung abgebrochen wird, wobei die vorhergehenden Schritte in der Aufgabe geänderte Daten in der Datenbank haben können, was in einem Verlust der Datenbankintegrität resultiert. Die Aufgabe kann abgebrochen werden, weil ein Schritt fehlgeschlagen ist, oder weil durch die Steuerung des Datenbankmanagers eine Aufgabe unterbrochen wurde, damit eine zweite Aufgabe durchgeführt wird, um für "gleichzeitige" Aufgabenverarbeitung zu sorgen. In einem solchen gleichzeitigen Szenario kann die Originalaufgabe niemals abgeschlossen werden, die Datenbank kann sogar als Ergebnis der abgeschlossenen Schritte in der Originalaufgabe geändert worden sein. Außerdem kann jede gleichzeitig ausgeführte Aufgabe in den gleichen Elementen aus der Datenbank funktionieren, wodurch eine zweite Aufgabe veranlaßt wird, fehlerhafte Daten, die von der ersten Aufgabe in der Datenbank plaziert wurden, zu ändern. Wiederum geht die Datenintegrität verloren.
In der Veröffentlichung INFORMATIONSTECHNIK IT, vol. 30, no. 1, 1988, MÜNCHEN, BR Seiten 17-27, U. KELTER: beschreibt der Artikel mit dem Titel "Transaktionskonzepte für Non-Standard-Datenbanksysteme" Konzepte zur gleichzeitigen Steuerung und Wiederherstellung, die für sogenannte Non-Standard-Datenbanksysteme geeignet sind, indem der zentrale Begriff der Designtransaktion eingeführt wird. Der Stand der Technik liefert das allgemeine Konzept, bei dem, bevor die Datenbankelemente aktualisiert werden, die Elemente in einen flüchtigen Speicher kopiert werden und die Operationen mit der Kopie der Elemente stattfinden. Schließlich werden die geänderten Elemente die Elemente in der Datenbank nur ersetzen, wenn die Operationen erfolgreich abgeschlossen wurden. Der Stand der Technik, der dieses Dokument enthält, beschreibt nicht oder empfiehlt nicht, wie die Operationen, die eine logische Sequenz von Aktivitäten durchführen, die eine Aktualisierung der Datenbank (Arbeitseinheit) zur Folge haben, mittels des objektorientierten Konzepts der Objektklasse, der Objekte und der Kapselungsverfahren in ein objektorientiertes System implementiert werden können.
Es ist deshalb ein Gegenstand der Erfindung, ein verbessertes Datenbankverwaltungssystem bereitzustellen.
Es ist ein weiterer Gegenstand der Erfindung ein verbessertes Datenbankverwaltungssystem bereitzustellen, das als objektorientiertes Programmierungssystem implementiert ist.
Es ist ein weiterer Gegenstand der Erfindung, ein verbessertes Datenbankverwaltungssystem bereitzustellen, das die Datenintegrität in einer Datenbank erhält.
Es ist ein weiterer Gegenstand der Erfindung, ein verbessertes Datenbankverwaltungssystem bereitzustellen, das die Datenintegrität der Datenbank ungeachtet einer Aufgabe erhält, die vor Beendigung abgebrochen wird.
Es ist noch ein weiterer Gegenstand der Erfindung ein Datenbankverwaltungssystem bereitzustellen, das die Datenintegrität der Datenbank während der Durchführung mehrerer gleichzeitigen Aufgaben erhält.
Die Erfindung ist in den Ansprüchen 1 und 3 definiert.
Diese und andere Gegenstände werden gemäß der Erfindung in einem Datenbankverwaltungssystem bereitgestellt, das eine Datenbank mit Datenelementen, die in einer Datenspeichereinheit gespeichert sind und einen Datenbankmanager enthält, der in einem Datenprozessor arbeitet, um mehrere Aufgaben in der Datenbank durchzuführen, wobei jede Aufgabe eine Anzahl mit Schritten enthält, die in der Lage sind, die Datenelemente in der Datenbank zu ändern. Gemäß der Erfindung enthält der Datenbankmanager eine Einheit des Arbeitsmanagers. Die Einheit des Arbeitsmanagers ordnet jeder Aufgabe eine Einheit des Arbeitsobjekts zu und erstellt für jeden Schritt in einer Aufgabe eine Einheit der Arbeitsebene. In einem objektorientierten Programmierungssystem ist die Arbeitseinheit eine neue Objektklasse, und ein Objekt aus der Einheit der Arbeitsobjektklasse wird für jedes Objekt erstellt, das im Rahmen einer Aufgabe zu bearbeiten ist.
Gemäß der Erfindung enthält jede Einheit der Arbeitsebene für eine Aufgabe eine Kopie der Datenelemente aus der Datenbank, die von der Aufgabe zu ändern sind. Jeder Schritt in der Aufgabe wird gesteuert, um die Datenelemente in der zugehörigen Einheit der Arbeitsebene zu ändern anstatt die Datenelemente in der Datenbank selbst. Demgemäß müssen, wenn eine Aufgabe vor Beendigung unterbrochen wird, nur die Datenelemente in der Einheit der Arbeitsebene geändert werden. Die Datenelemente in der Datenbank müssen nicht geändert werden. Ebenso kann, wenn der Datenbankmanager auf eine zweite Aufgabe schaltet, die Einheit der Arbeitsebenen gesichert werden und abgerufen werden, wenn die Aufgabe wiederaufgenommen wird.
Insbesondere wird gemäß der vorliegenden Erfindung eine Einheit der Arbeitsebene für jeden Schritt einer Aufgabe erstellt. Eine nachfolgende Einheit der Arbeitsebene bei einem nachfolgenden Schritt in einer Aufgabe enthält eine Kopie der Datenelemente, die von dem nachfolgenden Schritt in ihrem "as modified" Status aus der vorhergehenden Einheit der Arbeitsebene für den vorhergehenden Schritt zu bearbeiten ist. Diese "verschachtelten" Kopien liefern eine Historienverfolgung von Änderungen, die in den Daten durchgeführt wurden. Demgemäß werden, obgleich jeder Schritt in Daten arbeitet, wie diese aus dem vorhergehenden Schritt erscheinen, die aktuellen Daten in der Datenbank nicht geändert werden, bis der letzte Schritt in einer Aufgabe er folgreich abgeschlossen ist. Somit ist es möglich, Änderungen in den Daten in einer bestimmten Einheit der Arbeitsebene durch entsprechende Verschachtelung der Einheit der Arbeitsebenen zu "wiederholen".
Die Einheit des Arbeitsmanagers aus der vorliegenden Erfindung kann mit einzelnen Aufgaben-Datenbankverwaltungssystemen (d. h. Systeme, die zugleich eine Aufgabe ausführen) benutzt werden, um Datenintegrität bereitzustellen, falls die Aufgabe aus irgendeinem Grund nicht abgeschlossen oder abgebrochen wird. Außerdem kann die Einheit des Arbeitsmanagers aus der vorliegenden Erfindung mit simultanen Aufgaben-Datenbankverwaltungssystemen (d. h. Systemen, die gleichzeitig mehrere Aufgaben ausführen können) benutzt werden, um die Datenintegrität bereitzustellen, wenn die Aufgaben vor Abschluß geschaltet werden. In diesem Fall wird eine Kopie von jeder Einheit des Arbeitsobjekts für jede der vielen Aufgaben erstellt. Jede der vielen Kopien enthält ebenfalls mehrere Ebenen für jeden Schritt.
Die Einheit des Arbeitsmanagers aus der vorliegenden Erfindung kann in funktionell programmierten Datenbankverwaltungssystemen implementiert werden. Die Einheit des Arbeitsmanagers ist besonders für objektorientierte Programmierungssysteme vorteilhaft, weil diese Systeme normalerweise in sehr großen Datenbanken arbeiten und für Multitaskbetrieb geeignet sind. Objektorientierte Programmierungssysteme implementieren normalerweise eine "messy desk" Umgebung, in der zahlreiche Aktivitäten in der gleichen Anwendung stattfinden können. In einer solchen Umgebung ist die Datenintegrität schwer aufrechtzuerhalten.
In einem objektorientierten System ist die Arbeitseinheit der vorliegenden Erfindung eine Objektklasse, die Verfahren für "commit", "discard", "new", "notify", "rollback", "start" und "switch" enthält. Das Commit-Verfahren wendet die Änderungen an, die in der aktuellen Einheit der Arbeitsebene durchgeführt wurden, in der vorhergehenden Einheit der Arbeitsebene an. Wenn Commit durchgeführt wird, wenn die Einheit der Arbeitsebene "one" ist, erfolgt eine physische Aktualisierung der Datenbank. Discard entfernt die angegebene Einheit des Arbeitsobjekts aus dem System. Alle Daten in der entfernten Einheit des Arbeitsobjekts gehen verloren. Bei New beginnt eine ganz neue Einheit des Arbeitsobjekts. Notify wird von einem Anwendungsprogramm benutzt, um der Einheit des Arbeitsmanagers mitzuteilen, daß ein Datenelement gerade geändert wird. Rollback löscht die Änderungen, die in der aktuellen Einheit der Arbeitsebene durchgeführt wurden und fällt auf die vorhergehende Einheit der Arbeitsebene zurück. Bei Start beginnt eine neue verschachtelte Einheit der Arbeitsebene in der aktuellen Einheit des Arbeitsobjekts. Switch wird schließlich benutzt, um die aktuelle Einheit des Arbeitsobjekts zu verlassen und zu einer anderen zu gehen, der zuvor definierten Einheit des Arbeitsobjekts.
Insbesondere besteht die Erfindung aus einem Objektverwaltungssystem und -prozeß wie in den beiliegenden Ansprüchen beschrieben.
Mit Bezug auf die beiliegenden Zeichnungen wird die vorliegende Erfindung nachstehend nun ausführlicher beschrieben werden:
Fig. 1 zeigt eine schematische Darstellung eines Objekts.
Fig. 2 zeigt eine schematische Darstellung von dem Beispiel eines Objekts.
Fig. 3 zeigt die Vererbungseigenschaft der Objekte.
Fig. 4 zeigt ein schematisches Blockdiagramm eines objektorientierten Computersystems gemäß der vorliegenden Erfindung.
Fig. 5 zeigt ein schematisches Blockdiagramm eines objektorientierten Programms gemäß der vorliegenden Erfindung.
Fig. 6 zeigt eine schematische Darstellung einer Einheit des Arbeitsobjekts der vorliegenden Erfindung, die eine Vielzahl von Objekten und eine Einheit mit mehreren Arbeitsebenen enthält.
Fig. 7 zeigt eine schematische Darstellung der Objekttabelle für eine Einheit des Arbeitsobjekts gemäß der vorliegenden Erfindung.
Fig. 8 zeigt die Einheit mit mehreren Arbeitsobjekten gemäß der vorliegenden Erfindung.
Fig. 9 zeigt die Einheit mit mehreren Arbeitsobjekten nach dem Start einer neuen Ebene gemäß der vorliegenden Erfindung.
Fig. 10 bis Fig. 12 zeigen die Arbeitseinheiten aus der vorliegenden Erfindung vor und nach Implementierung der Switch- und Discard-Verfahren.
Fig. 13 zeigt ein schematisches Diagramm mit Operationen, die in einem ersten Beispiel der vorliegenden Erfindung implementiert sind.
Fig. 14 bis Fig. 16 zeigen Objekte im Speicher und in einer Datenbank während des Aufbaus der Einheit mit den Arbeitsebenen der vorliegenden Erfindung.
Die Fig. 17 und 18 zeigen Objekte im Speicher und in einer Datenbank während eines ersten Beispiels der vorliegenden Erfindung.
Fig. 19 zeigt ein schematisches Diagramm mit Operationen, die in einem zweiten Beispiel der vorliegenden Erfindung implementiert wurden.
Die Fig. 20 und 21 zeigen Objekte im Speicher und in einer Datenbank während eines zweiten Beispiels der vorliegenden Erfindung.
Fig. 22 zeigt ein schematisches Diagramm mit Operationen, die in einem dritten Beispiel der vorliegenden Erfindung implementiert wurden.
Die Fig. 23 und 24 zeigen Objekte im Speicher und in einer Datenbank während eines dritten Beispiels der vorliegenden Erfindung.
Fig. 25 zeigt ein schematisches Diagramm der Operationen, die in einem vierten Beispiel der vorliegenden Erfindung implementiert wurden.
Die Fig. 26 und 27 zeigen Objekte im Speicher und in einer Datenbank während eines vierten Beispiels der vorliegenden Erfindung.
In einem objektorientierten Computersystem wird die Arbeit durchgeführt, indem Aktionsanforderungsnachrichten an ein Objekt gesendet werden, das Daten enthält (in das Daten eingekapselt sind). Das Objekt wird die verlangte Aktion mit den Daten gemäß seinen vordefinierten Verfahren durchführen. Der Anforderer der Aktion muß nicht wissen, wie die aktuellen Daten aussehen, oder wie das Objekt diese bearbeitet.
Eine Objektklasse definiert die Arten und Bedeutungen von Daten und die Aktionsanforderungen (Nachrichten), die das Objekt honorieren wird. Die einzelnen Objekte, die Daten enthalten, werden Objektklassen genannt. Die Klassen beziehen sich im allge meinen auf reale Dinge. "Teile" kann beispielsweise eine Klasse sein. Die Datenelemente (Schlitze) eines Teils könnten eine Teilenummer, ein Status und eine Teileart sein. Die Objekte dieser Klasse stellen individuelle Teile dar, jeder mit seiner eigenen Teilenummer, dem eigenen Status und der eigenen Typinformation. Die Programme, welche die angeforderten Aktionen durchführen, werden Verfahren der Klasse genannt.
Objektklassen können als Unterklassen von anderen Klassen definiert werden. Unterklassen vererben alle Datencharakteristiken und Verfahren der Stammklasse. Sie können weitere Daten und Verfahren hinzufügen, und sie können Datenelemente oder Verfahren der Stammklasse auflösen (neu definieren). Obgleich die meisten Nachrichten an Objekte gesendet werden, wird die Nachricht, die verlangt, daß ein neues Objekt erstellt wird, an eine Objektklasse gesendet. Die Klasse wird veranlassen, daß ein neues Objekt erstellt wird und einen Objektbezeichner zurücksenden, durch den das Objekt erkannt werden wird.
Der Absender einer Aktionsanforderungsnachricht muß nicht die genaue Klasse des Objekts kennen, an die er die Nachricht senden wird. So lange das Zielobjekt entweder ein Verfahren definiert, um die Nachricht zu bearbeiten oder eine Stammklasse hat, die ein solches Verfahren definiert, wird die Nachricht mittels der Daten in der Objektklasse und des Verfahrens in ihrer Klasse oder ihrer Stammklasse bearbeitet. Tatsächlich muß es nicht eine direkte Stammklasse sein, sondern kann die Stammklasse einer Stammklasse sein usw. Der Absender des Verfahrens muß nur die Objekt-ID des Empfangsobjekts haben. Diese Eigenschaft der objektorientierten Systeme wird "Vererbung" genannt. Die Vererbungseigenschaft wird in der vorliegenden Erfindung benutzt.
Es wird nun auf Fig. 4 Bezug genommen, in der ein schematisches Blockdiagramm eines objektorientierten Computersystems 10 dargestellt ist. Das System 10 enthält einen Datenprozessor 11, der ein Mainframe-Computer, ein Minicomputer oder Personalcomputer sein kann. Für große Datenbanken mit mehreren Benutzern wird normalerweise ein Mainframe-Computer benutzt. Wie dem Fachmann bekannt ist, enthält der Datenprozessor 10 eine flüchtige Datenspeichereinheit 13, normalerweise ein Direktzugriffsspeicher (RAM), um einen Arbeitsspeicher für aktive Daten und Zwischenergebnisse bereitzustellen. Die Daten im RAM 13 werden gelöscht, wenn der Datenprozessor 11 ausgeschaltet wird, oder eine neue Benutzersitzung begonnen hat. Das System 10 enthält auch eine nichtflüchtige Datenspeichereinheit 14 zur dauerhaften Speicherung von Objekten. Die Einheit 14 kann eine direkte Zugriffsspeichereinheit (DASD - eine Plattendatei), eine Banddatei, eine löschbare Bildplatte oder eine andere bekannte Einheit sein. Die nichtflüchtige Datenspeichereinheit 14 wird hier auch als "Datenbank" bezeichnet. Die flüchtige Datenspeichereinheit 13 wird auch als "Speicher" bezeichnet. Eine Bildschirmstation 15 mit einer Kathodenstrahlröhre (CRT) oder ein anderer Bildschirm und eine Tastatur sind ebenfalls abgebildet.
Ein objektorientiertes Betriebsprogramm 12 ist ebenfalls im Datenprozessor 11 enthalten. Das objektorientierte Betriebsprogramm 12 kann in objektorientierten Sprachen programmiert sein, z. B. "C" oder "Smalltalk" oder Variationen von diesen Sprachen, oder in konventionellen Programmiersprachen wie FORTRAN oder COBOL. Das Design eines objektorientierten Betriebsprogramms 12 ist dem Fachmann von objektorientierten Systemen bekannt und wird nachstehend nur allgemein beschrieben.
Es wird nun auf Fig. 5 Bezug genommen, in der die Hauptkomponenten eines objektorientierten Programms (12, Fig. 4) beschrieben werden. Eine ausführlichere Beschreibung von Design und Betrieb eines objektorientierten Programms ist in "Object Oriented Software Construction" by Bertrand Meyer, das von Prentice Hall 1988 veröffentlicht wurde, enthalten.
Es wird nun Bezug auf Fig. 5 genommen. Das objektorientierte Programm 12 enthält drei primäre Komponenten: einen Messenger 51, eine Objektverwaltungstabelle 52 und eine Loaded-Classes- Tabelle 53. Der Messenger 51 steuert die Kommunikation zwischen anrufenden und angerufenen Nachrichten, der Objektverwaltungstabelle 52 und der Loaded-Classes-Tabelle 53. Die Objektverwaltungstabelle 52 enthält eine Liste mit Zeigern auf alle aktiven Objekte. Die Loaded-Classes-Tabelle 53 enthält eine Liste mit Zeigern auf alle Verfahren der aktiven Objektklassen.
Es wird nun der Betrieb des objektorientierten Programms 12 für das Beispiel beschrieben, das in Fig. 5 abgebildet ist, in dem Verfahren A (Block 54) eines Objekts eine Nachricht an Verfahren B (Block 55) eines Objekts sendet. Verfahren A sendet eine Nachricht an Verfahren B, indem der Messenger 51 aufgerufen wird. Die Nachricht enthält (1) eine Objektreferenz des Objekts, das die Nachricht empfangen wird, (2) das Verfahren des Objekts, das aufgefordert wird, die eingekapselten Daten auszuführen und (3) einige Parameter, die von dem Empfangsverfahren benötigt werden. Der Messenger 51 erhält einen Zeiger auf den Datenrahmen 56 des Objekts, das von Verfahren A angegeben wurde, indem die Objektverwaltungstabelle 52 nach dem Objekt durchsucht wird. Wenn das angegebene Objekt nicht gefunden werden kann, fügt die Objektverwaltungstabelle 52 das Objekt zur Tabelle hinzu und ruft das Objekt auf, um seine Daten aus der Datenbank zu materialisieren. Einmal in der Objekttabelle sendet die Objektverwaltungstabelle 52 den Zeiger zum materialisierten Objekt zurück.
Der Messenger 51 erhält dann die Adresse des Verfahrens B aus der Loaded-Classes-Tabelle 53. Wenn die Objektklasse nicht geladen ist, wird die Loaded-Classes-Tabelle 53 diese zu diesem Zeitpunkt laden, um ihre Daten zu materialisieren. Die Loaded- Classes-Tabelle 53 sucht nach dem angegebenen Verfahren (Verfahren B) und sendet die Adresse des Verfahrens an den Messenger 51 zurück.
Der Messenger 51 ruft dann über einen Systemdatenbereich Verfahren B und die Parameter aus dem Aufruf, der von Verfahren A gemacht wurde, einschließlich der Zeiger auf. Verfahren B greift mittels des Zeigers auf den Datenrahmen 56 zu. Verfahren B gibt dann die Steuerung an den Messenger 51 zurück, der die Steuerung an Verfahren A zurückgibt.
Das objektorientierte Programm 12 enthält normalerweise eine Tabelle für die Verfahren, die mit jedem Objekt verbunden sind. Diese Verfahrenstabelle enthält die Verfahrensnummer und die entsprechende Adresse, wo sich das Verfahren befindet. Das objektorientierte Programm 12 enthält normalerweise auch für jedes Objekt eine Objektidentifikationstabelle. Diese Tabelle enthält alle Objekte für das Objekt und für jedes Objekt die entsprechende Adresse oder OREF. Diese Tabellen werden für die Bearbeitung benutzt, um die Verfahren auszuführen und um auf Objekte sowie auf Daten der Objekte zuzugreifen.
In vielen Programmierungsaktivitäten und insbesondere in objektorientierten Programmierungssystemen ist es wünschenswert, eine Anzahl von Aufgaben unabhängig und parallel zu verarbeiten, ohne daß eine Aufgabe von der anderen beeinflußt wird. Viele Datenbanksysteme beschränken ein Programm auf eine einzelne, nacheinander ablaufende Aufgabe. Die primäre Beschränkung ist die Unfähigkeit, anzugeben, was festgeschrieben, wiederholt, gesperrt oder freigegeben sein sollte. Außerdem werden die Ressourcen im allgemeinen nach jeder Datenbankfestschreibung freigegeben. Diese Beschränkungen machen es schwierig, einem Benutzer zu erlauben, innerhalb einer "messy desk" Umgebung zu arbeiten, wo es zahlreiche gleichzeitige Aktivitäten in der gleichen Anwendung gibt.
Die Objektklasse "Arbeitseinheit" der vorliegenden Erfindung erlaubt es, daß eine oder mehrere Aktionen in einem Steuerkontext ausgeführt werden. In einem objektorientierten Programmierungssystem, das die Objektklasse "Arbeitseinheit" der vorliegenden Erfindung hat, identifiziert ein Anwendungsprogramm die Arbeitseinheiten. Das programmorientierte Programm 12 (Fig. 4) enthält eine Einheit des Arbeitsmanagers, der Anwendungsprogramme bereitstellt, welche die Fähigkeit haben, Daten zu verwalten und die relationale Integrität von zugehörigen Arbeitsaktivitäten zu erhalten.
Im Betrieb wird die Einheit des Arbeitsmanagers durch ein Anwendungsprogramm aufgerufen. Die Programme, welche Daten ändern, sind für die Benachrichtigung der Einheit des Arbeitsmanagers verantwortlich. Die Einheit des Arbeitsmanagers macht mehrere Kopien von dem gleichen Objekt, während eine Verarbeitungsaufgabe durch die Einheit der Arbeitsebenen durchgeführt wird. Diese Mehrfachobjekte liefern im wesentlichen eine Historienverfolgung der Änderungen, die in den Daten durchgeführt wurden. Somit ist es möglich, Änderungen in Daten in einer bestimmten Einheit der Arbeitsebene durch entsprechende Verschachtelung der Einheit der Arbeitsebenen zu "wiederholen". Die Einheit des Arbeitsmanagers wird von einer Aufgabe benutzt, um eine logische Einheit des Arbeitsobjekts zu steuern. Auf die Einheit des Arbeitsmanagers wird von der Aufgabe zugegriffen, die dann die Anforderungen an die Einheit des Arbeitsmanagers sendet, wie dies verlangt wird, um die aktuelle Einheit des Arbeitsobjekts zu bearbeiten.
Es wird nun auf Fig. 6 Bezug genommen. Es gibt zwei Hauptanwendungen für die Einheit der Arbeitsobjektklasse der vorliegenden Erfindung. Die erste Anwendung ist für die Einheit mit vielen gleichzeitigen Arbeitsebenen für jedes Objekt. Eine Objekttabelle, bekannt als Unit_Of_Work_Instance_Object_Table, wie in Fig. 7 dargestellt, ist für jede Einheit des Arbeitsobjekts vorhanden. Ein Beispiel von einer Einheit des Arbeitsobjekts für ein Objekt ist, wenn Object_A in Fig. 6 äquivalent zu dem Verkäuferobjekt in Fig. 3 war, dann wären die Mehrfach- Objekte des Verkäufers Objekt, d. h. Object_A würde B. Soutter, W. Tipp und B. G. Blue sein. Die Mehrfach-Arbeitsobjekte der Einheit sind in Fig. 8 abgebildet, wo Object_A, Object_B und Object_C in Fig. 6 gemeinsam als eine einzelne Einheit des Arbeitsobjekts dargestellt werden können, und Arbeitseinheit Instance_I, Arbeitseinheit Instance_II und Arbeitseinheit Instance_III zeigen drei Arbeitsobjekte der Einheit in Fig. 8. Die zweite Anwendung ist die Erstellung von Arbeitsebenen der Einheit in einer bestimmten Einheit des Arbeitsobjekts, das in Fig. 6 als UOW Ebene 1, UOW Ebene 2 und UOW 3 bezeichnet ist.
Die Mehrfach-Arbeitsobjekte der Einheit bedeuten nur, daß zwei oder mehr Arbeitseinheiten, die als Arbeitseinheit Instance_I, Arbeitseinheit Instance_II und Arbeitseinheit Instance_III in Fig. 8 bezeichnet sind, gleichzeitig vorhanden sein können und sogar unabhängig voneinander arbeiten können. Dies trifft auch für die Objekte selbst zu, z. B. Object_A, Object_B und Object_C in Fig. 6. Dieses Konzept ermöglicht Datenbankfestschreibungen, die nur eine bestimmte Einheit des Arbeitsobjekts für Object_A beeinflussen, z. B. die Arbeitseinheit Instance_I in Fig. 8. Die Mehrfach-Arbeitsobjekte der Einheit ermöglichen es einem Benutzer, wie gewünscht von der Einheit des Arbeitsobjekts zur Einheit des Arbeitsobjekts zu "schalten", d. h. Arbeitseinheit Instance_I zu Arbeitseinheit Instance_II. Die Einheit der Arbeitsebenen 1, 2 und 3 steuern die zu der Arbeitseinheit gehörenden Aktivitäten in einer bestimmten Einheit des Arbeitsobjekts. Nur Aktionen, welche die unterste Ebene einer bestimmten Einheit des Arbeitsobjekts festschreiben, d. h. Ebene 1, werden wirklich die Datenbank beeinflussen.

OBJEKTKLASSE ARBEITSEINHEIT - ATTRIBUTE

Die wichtigsten Attribute der Objektklasse der Arbeitseinheit aus der vorliegenden Erfindung enthalten:
Unit_of_Work_Instance_ID
Unit_of_Work_Instance_ID identifiziert einzigartig eine Einheit des Arbeitsobjekts.
Unit_of_Work_Instance_Current_Level
Unit_of_Work_Instance_Current_Level nennt die Einheit der Arbeitsebene für eine gegebene Einheit des Arbeitsobjekts.
Unit_of_Work_Previous_Instance ID
Unit_of_Work_Previous_Instance ID identifiziert einzigartig, welches Objekt gesteuert wurde, bevor die Steuerung an eine neu erstellte Einheit des Arbeitsobjekts oder einen Schalter übertragen wurde.
Unit_of_Work_Instance_Object_Table
(Unit_of_Work_Instance_Object_List)
Die Unit_of_Work_Instance_Object_Table wird für jede Einheit des Arbeitsobjekts gepflegt. Die zweidimensionale Tabelle enthält die Objekte für die Einheit des Arbeitsobjekts und die Einheit der Arbeitsebenen, in welchen das Objekt innerhalb der Einheit des Arbeitsobjekts gefunden wurde. Eine Implementierung stellt Spalten bereit, die nach Objekt gekennzeichnet sind, und Zeilen, die nach Einheit der Arbeitsebenen gekennzeichnet sind. Eine Adresse zum Objekt oder OREF wird am Schnittpunkt der bestimmten Objektspalte und der Zeile mit der Einheit der Arbeitsebene in der Tabelle behalten. Wo keine Adresse oder OREF gefunden wird, ist das Objekt in der bestimmten Ebene der Arbeitseinheit in der bestimmten Einheit des Arbeitsobjekts nicht vorhanden.
Mit Bezug auf Fig. 7 ist beispielsweise eine Unit_of_Work_Instance_Object_Table für die Einheit des Arbeitsobjekts in Fig. 6 dargestellt. Da es kein Objekt von Object_B in der Einheit der Arbeitsebene 2 oder von Object_C in der Einheit der Arbeitsebene 3 in der Einheit des Arbeitsobjekts gibt, das in Fig. 6 abgebildet ist, gibt es dementsprechend keinen Eintrag in der Unit_of_Work_Instance_Object_Table für diese Objekte in der Einheit dieser Arbeitsebenen.

OBJEKTKLASSE ARBEITSEINHEIT - VERFAHREN

Die Objektklasse der Arbeitseinheit aus der vorliegenden Erfindung liefert sieben Verfahren, die auf Objekte in der objektorientierten Umgebung wirken. Diese Verfahren enthalten New, Start, Notify, Discard, Switch, Commit und Rollback. Jedes Verfahren bearbeitet einen der obengenannten Zähler sowie andere Attribute.

New

Das Verfahren New beginnt eine vollkommen neue Einheit des Arbeitsobjekts und sendet dem aufrufenden Anwendungsprogramm einen Bezeichner zurück. Der Bezeichner identifiziert auf einzigartige Art und Weise die neue Einheit des Arbeitsobjekts. Alle Daten, die in dieser Einheit des Arbeitsobjekts angegeben sind, werden neu erstellt oder ausgewählt, selbst wenn die Daten bereits zuvor in einer anderen Einheit des Arbeitsobjekts ausgewählt wurden. Außerdem wird, wenn diese Einheit des Arbeitsobjekts abgelegt wird, der gesamte Speicher, der zu den Daten gehört, die in dieser Einheit des Arbeitsobjekts ausgewählt oder erstellt wurden, ebenfalls eingefroren.

Start

Das Verfahren Start informiert die Einheit des Arbeitsobjekts, eine neue verschachtelte Einheit des Arbeitsobjekts in der Einheit der aktuellen Arbeitsebene zu beginnen.

Notify

Das Verfahren Notify ermöglicht dem Anwendungsprogramm, die Einheit des Arbeitsobjekts zu informieren, daß ein Datenelement geändert werden muß und veranlaßt, daß das Datenelement in die aktuelle Einheit der Arbeitsebene in der aktuellen Einheit des Arbeitsobjekts "kopiert" wird.

Discard

Das Verfahren Discard entfernt die angegebene Einheit des Arbeitsobjekts aus dem Speicher, was im Verlust von Daten in der Einheit des Arbeitsobjekts resultiert, und keine Auswirkung auf die Datenbank hat.

Switch

Das Verfahren Switch veranlaßt die Steuerung, die aktuelle Einheit des Arbeitsobjekts zu verlassen und zu einer anderen, zuvor definierten Einheit des Arbeitsobjekts mittels der Steuerung zu gehen (Bezeichner oder einzigartiger Feldname), der von dem Funktionsmerkmal New zurückgeschickt wird.

Commit

Das Verfahren Commit wendet die Änderungen an, die in der aktuellen Einheit der Arbeitsebene gemacht wurden, die von der Unit_of_Work_Instance_Current_Level der vorhergehenden Einheit der Arbeitsebene genannt wurde. Commit wird durchgeführt, wenn die Einheit der Arbeitsebene eins ist, und resultiert in einer physischen Aktualisierung und einem Commit der Datenbank. Die Einheit des Arbeitsobjekts, bei der Commit erfolgreich durchgeführt wurde, wird sicherstellen, daß die Aktualisierung von jedem Datenelement erfolgreich war.

Rollbank

Das Verfahren Rollback löscht Änderungen, die in der aktuellen Einheit der Arbeitsebene durchgeführt wurden; die von der Unit_of_Work_Instance_Current_Level angegeben wurden und schickt die Steuerung an die vorhergehende Einheit der Arbeitsebene zurück. Wenn eine Datenbankoperation nicht erfolgreich war, wird die Einheit der Arbeitsebene als "un-committable" betrachtet. Die Datenbank wird per Roll back bearbeitet, alle Datenelemente werden in ihrem aktuellen Status in der Einheit der Arbeitsebene 1 im Speicher belassen und nicht in die Datenbank kopiert. Die Einheit des Arbeitsmanagers wird die Steuerung an das aufrufende Anwendungsprogramm zurückgeben, die das Commit mit einem Fehler ausgegeben hat, der das Datenelement nennt, das bei der Datenbankaktualisierung ausgefallen ist und den Grund für den Ausfall angibt.
Insbesondere mit Bezug auf Fig. 8, wird das Verfahren New eine neue Einheit des Arbeitsobjekts erstellen, d. h. Arbeitseinheit Instance_III, für das Objekt, das von dem Anwendungsprogramm angegeben wurde. New hat drei Attribute sowie einen Unit_of_Work_Instance_Current_Level für diese Einheit des Arbeitsobjekts, einen Anzeiger für die Einheit des vorhergehenden Arbeitsobjekts, die Unit_of_Work_Previous_Instance_ID, die angibt, welche Einheit des Arbeitsobjekts die Steuerung vor der Neuerstellung hatte, und eine Liste mit Objekten, über die diese neu erstellte Einheit des Arbeitsobjekts Bescheid weiß und die als Tabelle erstellt werden kann, die Unit_of_Work_Instance_Object_Table (Fig. 7). Es ist zu beachten, daß die Liste in Ebene Eins Kopien der Objekte enthalten wird, wie diese in der Datenbank erscheinen, und der Unit_of_Work_Instance_Current_Level wird auf eins gesetzt, da die Einheit des Arbeitsobjekts gerade erstellt wurde. Die Funktion von New wird außerdem in den Beispielen für die Verfahren Commit und Rollback beschrieben.
Das Verfahren Start erstellt eine neue Arbeitsebene in der aktuell aktiven Einheit des Arbeitsobjekts. Es gibt einen Unit_of_Work_Instance_Current_Level für jedes Objekt, das mitteilt, welche Einheit der Arbeitsebene in einer Einheit des Arbeitsobjekts aktuell aktiv ist. Dieser aktuelle Ebenenanzeiger im aktiven Objekt wird inkrementiert. Somit wird, wenn die Arbeitseinheit Instance_II die aktuell aktive Einheit des Arbeitsobjekts ist, Start_II die Einheit des Arbeitsmanagers veranlassen, eine neue Einheit der Arbeitsebene, nämlich Ebene 2, für die Arbeitseinheit Instance_II zu erstellen, da ihre aktuelle Ebene 1 ist. Der Unit_of_Work_Instance_Current_Level für diese Arbeitseinheit Instance_II wird um 1 inkrementiert, d. h. von 1 auf 2. Die Steuerung wird dann an das Anwendungsprogramm übergeben, das Start zusammen mit dem aktuellen Ebenenwert aufgerufen hat. Diese neue Ebene resultiert in Änderungen in Fig. 8, wie dies in Fig. 9 dargestellt ist. Die Funktion von Start wird außerdem in den Beispielen für die Verfahren Commit und Rollback ausführlich beschrieben.
Das Verfahren Notify versorgt die Einheit des Arbeitsmanagers mit einer Information vom Anwendungsprogramm, daß ein Datenelement zu ändern ist. Die Ebene, die von dem Unit_of_Work_Instance_Current_Level von der aktiven Einheit des Arbeitsobjekts angegeben wird, wird geprüft, um festzustellen, ob die Ebene eine Kopie der Daten hat. Wenn in der aktuellen Einheit der Ebene mit dem aktiven Arbeitsobjekt keine Kopie vorhanden ist, wird der Speicher zugeordnet und eine Kopie des Originalobjekts wird in dieser Ebene erstellt. Eine Implementierung liefert einen Zeiger, der gesetzt wird, um auf die vorherige Kopie des Objekts zu zeigen. Die Funktion von Notify wird außerdem in den Beispielen von den Verfahren Commit und Rollback beschrieben.
Das Verfahren Discard entfernt die aktuell aktive Einheit des Arbeitsobjekts aus dem Speicher. Dies geschieht, indem alle Einträge in der Objektidentifikationstabelle gelöscht werden, welche die Objektidentifikationsnummer und die zugehörige Adresse hat, die sich auf die aktuell aktive Einheit des Arbeitsobjekts für das bestimmte Objekt beziehen. Diese bestimmte Einheit des Arbeitsobjekts wird aus der Liste der Objekte in der Originaleinheit des Arbeitsobjekts entfernt. Die Unit_of_Work_Instance_Object_Table wird ebenfalls aus dem Speicher entfernt. Die Funktion und die Implementierung des Verfahrens Discard werden außerdem in den Beispielen von den Verfahren Commit und Rollback beschrieben.
Das Verfahren Switch ermöglicht die Änderung der Steuerung aus der aktuell aktiven Einheit des Arbeitsobjekts in eine zuvor definierte Einheit des Arbeitsobjekts. Das Verfahren liefert drei Attribute, die zu jeder Einheit des Arbeitsobjekts gehören, die das Verfahren Switch benutzen, nämlich einen Unit_of_Work_Instance_Current_Level, einen Anzeiger auf die vorherige Einheit des Arbeitsobjekts, d. h. Unit_of_Work_Previous_Instance_ID und eine Liste der Objekte, welche die aktuell aktive Einheit des Arbeitsobjekts kennt, d. h. die Unit_of_Work_Instance_Object_Table. Es ist zu beachten, daß Switch nur in der aktuell aktiven Ebene eines Objekts durchgeführt wird und nicht in den vorhergehenden Ebenen eines Objekts.
Es wird nun Bezug auf Fig. 10 genommen, in der das Verfahren Switch weiter beschrieben werden wird. In Fig. 10 enthalten die Arbeitsobjekte der Einheit, nämlich UOW_I, UOW_II und UOW_III, ein oder mehrere Objekte, und es wird verstanden werden, daß jede Einheit des Arbeitsobjekts mehr als eine Einheit des Arbeitsobjekts enthalten kann. Das Objekt ganz rechts, nämlich UOW_III, ist das aktuell aktive Objekt. Referenzen auf neue Arbeitsobjekte der Einheit und vorhergehende Arbeitsobjekte der Einheit bleiben erhalten. Wenn das Anwendungsprogramm einen Switch ausführt, um die Einheit des Arbeitsobjekts UOW_I zu informieren, wird der vorhergehende aktive Objektzeiger für die Einheit des Arbeitsobjekts UOW_II auf den vorhergehenden aktiven Zeiger für die Einheit des Arbeitsobjekts UOW_I gesetzt, d. h. null, wobei der vorherige aktive Zeiger für die Einheit des Arbeitsobjekts UOW_I auf das aktuell aktive Objekt gesetzt wird, d. h. zeigt auf die Einheit des Arbeitsobjekts UOW_III, und das aktuell aktive Objekt wird auf die Einheit des Arbeitsobjekts UOW_I gesetzt. Der neue Zeiger für die Einheit des Arbeitsobjekts UOW_III und UOW_I wird auf die Einheit des Arbeitsobjekts UOW_I bzw. null setzt. Somit wird mit Bezug auf Fig. 11 die Einheit des Arbeitsobjekts UOW_1 aus ihrer gegenwärtigen Position in der Liste an das Ende der Liste verschoben, wodurch Zeiger auf vorherige Arbeitsobjekte angeglichen werden, so daß der vorherige Objektzeiger von UOW_I auf UOW_III zeigt, und der vorherige Zeiger von UOW_III auf UOW_II.
Wenn ein Discard A vom Anwendungsprogramm ausgeführt wurde, dann würde der Anzeiger, der angibt, daß die Einheit des Arbeitsobjekts UOW_I derzeit aktiv war, auf das angeglichen, auf das der vorherige Objektzeiger der Einheit des Arbeitsobjekts UOW_I zeigt, nämlich auf die Einheit des Arbeitsobjekts UOW_III. Der neue Zeiger für die Einheit des Arbeitsobjekts UOW_III wird auf null gesetzt. Alle Einträge in der Objektidentifikationstabelle für die Einheit des Arbeitsobjekts UOW_I werden gelöscht. Somit ist die Einheit des Arbeitsobjekts UOW_III das aktuell aktive Objekt. Das Ergebnis dieses Discard- Verfahrens ist in Fig. 12 dargestellt.
Um die Funktion der Commit- und Rollback-Verfahren aus der vorliegenden Erfindung umfassend zu beschreiben, wird die Funktion dieser Verfahren anhand von vier Beispielen erläutert. Die Funktion der anderen fünf Verfahren, nämlich Now, Start, Notify, Discard und Switch, werden als Teil dieser Beispiele erscheinen. Beispiel 1 beschreibt die Funktion eines Modify-Verfahrens in Object_A und Object_B in zwei Arbeitsebenen der Einheit in einer Einheit des Arbeitsobjekts, die am Ende von jeder Ebene Commit werden. Beispiel 2 beschreibt die Funktion eines Modify-Verfahrens in Object_A und Object_B in zwei Arbeitsebenen der Einheit in einer Einheit des Arbeitsobjekts, die nicht erfolgreich abgeschlossen wurde und deshalb am Ende der Ebene Rollback werden. Beispiel 3 beschreibt die Funktion eines Modify-Verfahrens in Object_A und Object_B in zwei Arbeitsebenen der Einheit in einer Einheit des Arbeitsobjekts, wobei die inneare Ebene mit einem Fehler abschließt und wiederholt wird, und die äußere Ebene erfolgreich abgeschlossen und festgeschrieben wird. Beispiel 4 beschreibt die Funktion eines Modify-Verfahrens in Object_A und Object_B in zwei Arbeitsebenen der Einheit in einer Einheit des Arbeitsobjekts, wobei die innere Ebene erfolgreich abgeschlossen und festgeschrieben wird, und die äußere Ebene erfolglos abgeschlossen und wiederholt wird.
In allen Beispielen wird der Begriff "Datenbank" benutzt, um eine nichtflüchtige Datenspeichereinheit zu bezeichnen. Die Begriffe "RAM" und "Speicher" werden benutzt, um eine flüchtige Datenspeichereinheit zu bezeichnen.
Bei jedem Beispiel wird angenommen, daß zwei Datenobjekte, nämlich Object_A und Object_B, vorhanden sind. Die Attribute von beiden Objekten werden am Anfang von jedem Beispiel initialisiert.
Object_A hat ein numerisches Attribut, Feld X genannt, bei dem der Wert 100 in der physischen Datenbank gespeichert ist.
Object_B hat ein Zeichenbereichsattribut der Länge 3, Feld Y genannt, bei dem der Wert "ABC" in der Datenbank gespeichert ist.

BEISPIEL 1--COMMIT-COMMIT

In diesem Beispiel werden Object_A und Object_B in zwei Arbeitseinheiten geändert, wobei eines im anderen innerhalb einer Einheit des Arbeitsobjekts verschachtelt ist. Das Modify-Verfahren wird mit den Arbeitseinheitsverfahren aus dieser Erfindung ausgeführt. Zum Zweck dieser Darstellung wird jede Einheit der Arbeitsebene erfolgreich abgeschlossen und am Ende festgeschrieben. Das Commit-Verfahren wird am Ende von jeder Einheit der Arbeitsebene benutzt. Dieses Beispiel ist in Fig. 13 dargestellt.
Die Funktion der Verfahren der Arbeitseinheit läuft ab wie bereits definiert und wie diese für das Commit-Verfahren beschrieben werden wird. Ein High-Level-Programm trifft eine Entscheidung, eine Einheit des Arbeitsobjekts zu beginnen. Das Verfahren New der Arbeitseinheit wird aufgerufen. New ordnet die nächste Einheit des Arbeitsobjekts zu und gibt den Bezeichner (einzigartiger Feldname der Einheit des Arbeitsobjekts) an die High = Level-Routine zurück. Alle Daten in dieser Einheit des Arbeitsobjekts werden neu erstellt oder ausgewählt. Für dieses Objekt wird ein aktueller Ebenenzähler (Unit_of_Work_Instance_Current_Level) vereinbart und auf eins gesetzt. Ein vorheriger Objektzähler (Unit_of_Work_Previous_Instance_ID) wird vereinbart und auf die Referenz der vorherigen Einheit der Arbeitseinheit gesetzt, welche die Steuerung hatte.
Die High-Level-Routine beschließt dann, eine Operation zu beginnen, welche die Steuerung der Arbeitseinheit benötigt. Diese Routine ruft das Start-Verfahren der Arbeitseinheit auf, um eine neue Arbeitsebene zu erstellen. Die Start-Routine der Arbeitseinheit inkrementiert den Ebenenzähler für die aktive Einheit des Arbeitsobjekts (Unit_of_Work_Instance_Current_Level) um zwei. Die Start-Routine sendet die Steuerung an ihren Anforderer zurück und überträgt den Wert der aktuellen Ebene der Arbeitseinheit, d. h. Ebene zwei, zurück.
Die High-Level-Routine ruft dann für Object_A die Modify_A Routine auf. Die Modify_A Routine ruft die Notify-Routine der Arbeitseinheit auf, während sie versucht, die Daten zu ändern und überträgt die Identifikation von diesem Object_A, das aus der Objektidentifikationstabelle stammt. Die Notify-Routine der Arbeitseinheit prüft die Unit_of_Work_Instance_Object_Table, um festzustellen, ob eine Kopie von Object_A in der aktuellen Einheit der Arbeitsebene (Unit_of_Work_Instance_Current_Level), nämlich Ebene 2, vorhanden ist. Da Object_A nicht in der Einheit der Arbeitsebene 2 ist, ordnet die Notify-Routine der Arbeitseinheit einen entsprechend bemessenen Speicherblock zu und kopiert die aktuelle Version der Daten in diesem Block. Die Adresse oder OREF von diesem Block wird in der Unit_of_Work_Instance_Object_Table für Object_A in Ebene 2 gespeichert. Die Notify-Routine der Arbeitseinheit sendet die Steuerung an die Modify_A Routine zurück.
Die Modify_A Routine geht dann zu der Aufgabe über, die Daten zu ändern. Feld X ist beispielsweise gleich 50 gesetzt. Datenbank und Speicher können nun wie in Fig. 14 dargestellt, angezeigt werden. Wenn Modify_A ihre Arbeit beendet hat, wird die Steuerung an die anfordernde High-Level-Routine zurückgegeben.
Die High-Level-Routine ruft dann die Start-Routine der Arbeitseinheit auf, um anzugeben, daß sie mit einer anderen verschachtelten Einheit der Arbeitsebene beginnen möchte. Die Start-Rou tine der Arbeitseinheit inkrementiert den Zähler der aktiven Ebene für die aktuell aktive Einheit des Arbeitsobjekts (Unit_of_Work_Instance_Current_Level) um drei. Start sendet die Steuerung an ihren Anforderer und gibt den Wert von der aktiven Einheit der Arbeitsobjektebene, d. h. 3, zurück.
Die High-Level-Routine ruft dann die Modify_A Routine für Object_A auf, wie in Fig. 13 dargestellt. Die Modify_A Routine ruft, die Notify-Routine der Arbeitseinheit auf, während sie versucht, die Daten zu ändern. Modify überträgt die Identifikation von Object_A, die aus der Objektidentifikationstabelle stammt, an Notify. Notify prüft die Unit_of_Work_Instance_Object_Table, um festzustellen, ob eine Kopie von Object_A in der aktuellen Einheit der Arbeitsebene existiert. Da Object_A nicht in der aktuellen Einheit der Arbeitsebene (Unit_of_Work_Instance_Current_Level) vorhanden ist, d. h. Ebene 3, ordnet Notify einen entsprechend bemessenen Speicherblock zu und kopiert die aktuelle Version von Object_A in diesen Block. Die Adresse dieses Blocks wird in die Unit_of_Work_Instance_Object_Table für Object_A in Ebene 3 geladen. Die Notify-Routine der Arbeitseinheit sendet die Steuerung an die Modify_A Routine zurück.
Modify_A geht dann geht dann zu der Aufgabe über, Object_A zu ändern. Feld X ist beispielsweise gleich 25 gesetzt. Datenbank und Speicher können nun wie in Fig. 15 dargestellt, angezeigt werden. Wenn Modify_A ihre Arbeit beendet hat, wird die Steuerung an die anfordernde High-Level-Routine zurückgegeben.
Die High-Level-Routine ruft dann die Modify_B Routine für Object_B auf. Die Modify_B Routine in Fig. 13 ruft die Notify- Routine der Arbeitseinheit auf, während sie versucht, Object_B zu ändern. Modify überträgt die Identifikation von Object_B, die aus der Objektidentifikationstabelle stammt, an Notify. Notify-Routine der Arbeitseinheit prüft die Unit_of_Work_Instance_Object_Table, um festzustellen, ob eine Kopie von Object_B in der aktuellen Einheit der Arbeitsebene (Unit_of_Work_Instance_Current_Level), d. h. Ebene 3, existiert. Da Object_B nicht in der aktuellen Einheit der Arbeitsebene vorhanden ist, d. h. Ebene 3, ordnet Notify einen entsprechend bemessenen Speicherblock zu. Notify kopiert die aktuelle Version von Object_B aus Ebene 1 in diesen Block in Ebene 3. Die Unit_of_Work_Instance_Object_Table wird aktualisiert, um das Vorhandensein und die Speicherstelle der Kopie von Object_B in Ebene 3 wiederzugeben. Die Notify-Routine der Arbeitseinheit sendet die Steuerung an die Modify_B Routine zurück.
Modify_B geht dann zu der Aufgabe über, Object_B zu ändern. Feld Y ist beispielsweise gleich "DEF" gesetzt. Datenbank und Speicher können nun angezeigt werden, wie in Fig. 16 dargestellt. Es ist zu beachten, daß für Object_B keine Ebene 2 existiert. Dies ist ein Ergebnis, das zeigt, daß Object_B nicht bearbeitet wurde, während der aktuelle Ebenenzähler (Unit_of_Work_Instance_Current_Level) gleich 2 gesetzt wird. Wenn die Modify_B Routine ihre Aufgabe abgeschlossen hat, wird die Steuerung an die aufrufende High-Level-Routine zurückgegeben.
Die High-Level-Routine bestimmt, daß die Einheit der Arbeitsebene drei zufriedenstellend abgeschlossen wurde und ruft die Commit-Routine der Arbeitseinheit auf. Bei diesem Beispiel wird von dem erfolgreichen Abschluß ausgegangen, um Commit darzustellen. Commit prüft die Unit_of_Work_Instance_Object_Table, um alle Datenobjekte zu suchen, deren Einheit der Arbeitsebene gleich der aktuellen Einheit der Arbeitsebene (Unit_of_Work_Instance_Current_Level) ist. Da die aktuelle Ebene drei ist, werden sowohl Object_A als auch Object_B in Ebene drei gefunden. Es wird eine Überprüfung durchgeführt, um festzustellen, ob eine Kopie von jedem Objekt in der Ebene vor der aktuellen Ebene vorhanden ist. In diesem Fall erfolgt eine Prüfung, um festzustellen, ob eine Kopie von Object_A und Ob ject_B in Ebene zwei vorhanden ist. Da eine Kopie von Object_A in Ebene zwei vorhanden ist, wird die Commit-Routine der Arbeitseinheit Object_A in Ebene 2 aus dem Speicher entfernen und Object_A aus Ebene drei erstellen, wie dieses aktuell in Ebene zwei "aktiv" ist. Somit werden die Inhalte aus der Unit_of_Work_Instance_Object_Table in Object_A und Ebene 2 durch die aus Ebene 3 ersetzt. Da Object_B keine Kopie im Speicher in der Einheit der Arbeitsebene zwei hat, wird Commit die Einheit der Arbeitsebene von Object_B von drei in zwei ändern. So werden die Inhalte aus der Unit_of_Work_Instance_Object_Table in Object_B, Ebene 3, in Ebene 2 verschoben.
Die Commit-Routine der Arbeitseinheit subtrahiert eins von der Einheit des Arbeitsebenenzählers (Unit_of_Work_Instance_Current_Level). Die neue Einheit der Arbeitsebene ist nun zwei. Die Commit-Routine der Arbeitseinheit gibt die Steuerung an die High-Level-Routine zurück. Datenbank und Speicher können nun angezeigt werden, wie dies in Fig. 17 dargestellt ist, in der die vorhergehende Ebene von der aktuellen Ebene überdeckt wird.
Die High-Level-Routine bestimmt, daß die Einheit der Arbeitsebene zwei zufriedenstellend abgeschlossen wurde und ruft die Commit-Routine der Arbeitseinheit auf. Bei diesem Beispiel wird der erfolgreiche Abschluß angenommen, um Commit darstellen zu können. Die Commit-Routine der Arbeitseinheit prüft die Unit_of_Work_Instance_Object_Table, um alle Datenobjekte, die in der aktuellen Einheit der aktiven Arbeitsebene (Unit_of_Work_Instance_Current_Level) vorhanden sind, herauszufinden. Da die aktuelle Ebene zwei ist, werden sowohl Object_A als auch Object_B gefunden. Wenn die aktuell aktive Ebene zwei ist, wird Commit versuchen, die Datenbank zu aktualisieren. Da die Einheit des Arbeitsebenenwerts (Unit_of_Work_Instance_Current_Level) in dem Beispiel zwei ist, wird Commit versuchen, die Datenbank mit den neuen Daten zu aktualisieren, die in Object_A und Object_B in Ebene zwei gefunden wurden. Dann wird der Befehl in der entsprechenden Datenbankabfragesprache ausgegeben, so daß die Änderungen physisch auf die Datenbank angelegt werden. In diesem Beispiel wird angenommen, daß die Datenbankaktualisierungen erfolgreich sind.
An diesem Punkt wird die Commit-Routine der Arbeitseinheit Object_A und Object_B in Ebene eins aus dem Speicher freigeben, die Ebenenanzeigen für Object_A und Object_B in Ebene zwei auf Ebene eins setzen und Object_A und Object_B als aktuell "aktiv" erstellen. Die Inhalte der Unit_of_Work_Instance_Object_Table in Object_A, Ebene 1 und Object_B in Ebene 1 werden aktualisiert, indem diese jeweils durch die Inhalte aus Object_A, Ebene 2 und Object_B, Ebene 2 ersetzt werden.
Die Commit-Routine der Arbeitseinheit subtrahiert eins von der Einheit des aktuellen Arbeitsebenenzählers (Unit_of_Work_Instance_Current_Level). Somit ist der aktuell aktive Ebenenzähler für dieses Objekt jetzt eins. Die Commit- Routine der Arbeitseinheit kehrt dann zur High-Level-Routine zurück. Datenbank und Speicher können nun, wie in Fig. 18 dargestellt, angezeigt werden.
Die High-Level-Routine gibt dann ein Discard aus, um die Einheit des Arbeitsobjekts zu entfernen. Somit wird die Identifikation von Object_A und Object_B aus der Objektidentifikationstabelle im Speicher gelöscht. Die Einheit der Arbeitsebene eins wird ebenfalls aus dem Speicher gelöscht. Die Einheit der Arbeitsebene eins wird auch aus dem Speicher entfernt. Die Unit_of_Work_Instance_Object_Table für die Einheit der Arbeitsebene wird aus dem Speicher gelöscht. Die Datenbank bleibt wie dargestellt in Fig. 18. Die High-Level-Routine wird dann beendet und kehrt zu ihrem Anforderer zurück.

BEISPIEL 2--ROLLBACK-ROLLBACK

In einem zweiten Beispiel werden Object_A und Object_B in zwei Arbeitseinheiten geändert, wobei eines in all den anderen innerhalb einer Einheit des Arbeitsobjekts verschachtelt ist. Zum Zweck dieser Darstellung wird jede Einheit der Arbeitsebene nicht erfolgreich abgeschlossen. Dieses Beispiel ist in Fig. 19 dargestellt.
Eine High-Level-Routine in einem Anwendungsprogramm trifft eine Entscheidung, um mit einer Einheit des Arbeitsobjekts zu beginnen. Das New-Verfahren der Arbeitseinheit wird aufgerufen. Ein aktueller Ebenenzähler (Unit_of_Work_Instance_Current_Level) für das neue Objekt wird vereinbart und auf eins initialisiert. Eine vorherige Einheit des Arbeitsobjektanzeigers (Unit_of_Work_Previous_Instance_ID) wird vereinbart und gesetzt, um das Objekt anzugeben, das die Steuerung vorher hatte. New vereinbart auch eine Liste, um die Objekte zu speichern, über die dieses Objekt Bescheid weiß. Diese Liste kann als Tabelle, Unit_of_Work_Instance_Object_Table, dargestellt werden und enthält die Adressen des Objekts in den verschiedenen Ebenen. Die Objekte aus der Datenbank werden in die Tabelle (Liste) in Ebene eins kopiert. New weist den nächsten Bezeichner der Arbeitseinheit (einzigartiger Feldname) zu und überträgt diesen zurück an die High-Level-Routine. Die High-Level- Routine beschließt, eine Operation zu beginnen, welche die Steuerung der Arbeitseinheit benötigt. Diese Routine ruft die Start-Routine der Arbeitseinheit auf. Start erstellt eine neue Arbeitsebene in diesem aktuell aktiven Objekt. Start inkrementiert den aktuellen Ebenenzähler der Arbeitseinheit um ein. Somit ist die aktuell aktive Ebene (Unit_of_Work_Instance_Current_Level) in diesem Objekt zwei. Das Start-Verfahren der Arbeitseinheit gibt die Steuerung an ihren Anforderer zurück und überträgt den Wert des aktuellen Ebenenzählers der Arbeitseinheit, der zwei ist, zurück.
Die High-Level-Routine ruft dann das Modify_A Verfahren für Object_A auf - wie in Fig. 19 dargestellt. Da Modify_A versucht, die Daten zu bearbeiten, ruft es das Notify-Verfahren der Arbeitseinheit auf, das dem Arbeitseinheitenmanager angibt, daß Object_A geändert werden muß. Modify überträgt die Identifikation von Object_A, die es ändern wird. Diese stammt aus der Objektidentifikationstabelle. Das Notify-Verfahren der Arbeitseinheit prüft die Unit_of_Work_Instance_Object_Table, um festzustellen, ob eine Kopie von Object_A in der aktuellen Einheit der Arbeitsebene (Unit_of_Work_Instance Current level) vorhanden ist. Da Object_A für dieses Objekt nicht in der aktuellen Einheit der Arbeitsebene ist, d. h. Ebene zwei, weist das Notify-Verfahren einen entsprechend bemessenen Speicherblock zu. Notify kopiert dann die aktuelle Version von Object_A aus Ebene eins in diesen Block in Ebene zwei. Die Unit_of_Work_Instance_Object_Table in Object_A, Ebene 2, wird mit der Adresse dieses Blocks geladen. Die Notify-Routine der Arbeitseinheit gibt die Steuerung der Modify_A Routine zurück.
Das Modify_A Verfahren ändert dann die Daten. Feld X wird beispielsweise gleich 50 gesetzt. Datenbank und Speicher können dargestellt werden, wie dies in Fig. 14 abgebildet ist. Wenn Modify_A die Änderung der Daten abgeschlossen hat, wird die Steuerung an die aufrufende High-Level-Routine zurückgegeben.
Die High-Level-Routine ruft dann das Start-Verfahren der Arbeitseinheit auf, um anzugeben, daß es mit einer anderen, verschachtelten Einheit des Arbeitsobjekts beginnen möchte. Start erstellt eine neue Arbeitsebene in der aktuellen Einheit des Arbeitsobjekts. Das Start-Verfahren der Arbeitseinheit inkrementiert den aktuellen Ebenenzähler für dieses Objekt (Unit_of_Work_Instance_Current_Level) um drei. Start schickt die Steuerung an ihren Anforderer zurück und überträgt den Wert des aktuellen Ebenenzählers der Arbeitseinheit, d. h. Ebene drei, zurück.
Die High-Level-Routine ruft dann das Modify_A Verfahren für Object_A auf. Modify_A ruft die Einheit der Arbeitsroutine auf und überträgt die Identifikation von Object_A. Es erhält die Identifikation von Object_A aus der Objektidentifikationstabelle und überträgt diese an Notify. Das Notify-Verfahren der Arbeitseinheit prüft die Unit_of_Work_Instance_Object_Table, um festzustellen, ob eine Kopie von Object_A in der aktuellen Einheit der Arbeitsebene (Unit_of_Work_Instance_Current_Level), d. h. Ebene drei, vorhanden ist. Dies wird dadurch bestimmt, ob ein Eintrag (Adresse) in der Unit_of_Work_Instance_Object_Table für Object_A in Ebene 3 vorhanden ist. Da Object_A nicht in der aktuellen Einheit der Arbeitsebene (Unit_of_Work_Instance_Current_Level) vorhanden ist, weist Notify ein entsprechend bemessener Speicherblock zu. Die aktuelle Version von Object_A aus Ebene zwei wird in diesen Block in Ebene drei kopiert. Die Adresse dieses Blocks wird in die Unit_of_Work_Instance_Object_Table in Object_A, Ebene 3, geladen. Das Notify-Verfahren der Arbeitseinheit schickt die Steuerung an das Modify_A Verfahren zurück.
Dann ändert Modify_A Object_A. Feld X wird beispielsweise gleich 25 gesetzt. Datenbank und Speicher können nun dargestellt werden, wie dies in Fig. 15 abgebildet ist. Wenn Modify_A ihre Aufgabe abgeschlossen hat, wird die Steuerung an die aufrufende High-Level-Routine zurückgeschickt.
Die High-Level-Routine ruft dann das Modify_B Verfahren für Object_B auf. Modify_B ruft das Notify-Verfahren der Arbeitseinheit auf, um dem Arbeitseinheitsmanager mitzuteilen, daß Object_B zu ändern ist. Modify erhält die Identifikation von Object_B aus der Objektidentifikationstabelle und überträgt diese an Notify. Das Notify-Verfahren der Arbeitseinheit prüft die Unit_of_Work_Instance_Object_Table, um festzustellen, ob eine Kopie von Object_B in der aktuellen Einheit der Arbeitsebene, d. h. Ebene drei, vorhanden ist. Da Object_B nicht in der Unit_of_Work_Instance_Current_Level vorhanden ist, weist Notify einen entsprechend bemessenen Speicherblock zu. Notify kopiert dann die aktuelle Version, d. h. die Version aus Ebene eins in diesen Block in Ebene drei. Die Adresse dieses Blocks wird in die Unit_of_Work_Instance_Object_Table in Object_B, Ebene 3, geladen. Das Notify-Verfahren der Arbeitseinheit kehrt zu dem Modify_B Verfahren zurück.
Modify_B ändert dann Object_B. Feld Y wird beispielsweise gleich "DEF" gesetzt. Datenbank und Speicher können nun dargestellt werden, wie diese in Fig. 16 abgebildet sind. Wenn das Modify_B Verfahren seine Aufgabe beendet hat, wird die Steuerung an die aufrufende High-Level-Routine zurückgeschickt.
Die High-Level-Routine bestimmt, daß die Einheit der Arbeitsebene drei nicht zufriedenstellend abgeschlossen wird und ruft das Rollback-Verfahren der Einheit auf. Es ist zu beachten, daß zur Darstellung von Rollback ein nicht zufriedenstellender Abschluß angenommen wurde. Die Rollback-Routine der Arbeitseinheit findet alle Datenobjekte, die im aktuellen Unit_of_Work_Instance_Current_Level, d. h. Ebene drei, vorhanden sind. Dies geschieht, indem alle Objekte mit Einträgen in dieser Ebene in der Unit_of_Work_Instance_Object_Table gefunden werden. In diesem Beispiel haben sowohl Object_A als auch Object_B Ebenenanzeiger gleich Ebene drei.
Wenn eine Kopie des Objekts in der Ebene vorhanden ist, die eine Ebene unter der aktuellen Ebene liegt, wird die aktuelle Ebene gelöscht, und die darunter liegende Ebene wird aktuell aktiv. Wenn eine Kopie in einer Ebene unterhalb der aktuellen Ebene nicht vorhanden ist, wird die Kopie in der aktuellen Ebene gelöscht, und die am nächsten darunter liegende Kopie, die vorhanden ist, wird aktuell aktiv. Da Object_A eine Kopie im Speicher in der Einheit der Arbeitsebene zwei hat, wir das Rollback-Verfahren der Arbeitseinheit den Speicher für Object_A in Ebene drei freigeben und Object_A in Ebene zwei als aktuell "aktiv" erstellen. Dadurch wird der Eintrag in der Unit_of_Work_Instance_Object_Table in Object_A, Ebene 3, gelöscht. Da Object_B keine Kopie im Speicher in der Einheit der Arbeitsebene zwei hat, wird das Rollback-Verfahren den Speicher von Object_B in Ebene drei freigeben und Object_B in Ebene eins als aktuell "aktiv" erstellen. Dadurch wird der Eintrag in der Unit_of_Work_Instance_Object_Table in Object_B, Ebene 3, gelöscht.
Dann subtrahiert Rollback eins von dem aktuellen Ebenenzähler der Arbeitseinheit (Unit_of_Work_Instance_Current_Level). Die neue aktuelle Einheit der Arbeitsebene ist jetzt zwei. Das Rollback-Verfahren der Arbeitseinheit schickt die Steuerung an die High-Level-Routine zurück. Datenbank und Speicher können nun dargestellt werden, wie in Fig. 20 abgebildet.
Die High-Level-Routine bestimmt, daß die Einheit der Arbeitsebene zwei nicht zufriedenstellend abgeschlossen wurde und ruft deshalb die Rollback-Routine der Arbeitseinheit auf. Es ist zu beachten, daß zur Darstellung von Rollback der nicht zufriedenstellende Abschluß angenommen wurde. Die Rollback-Routine der Arbeitseinheit findet alle Datenobjekte, die in der aktuellen Einheit der Arbeitseinheit vorhanden sind (Unit_of_Work_Instance_Current_Level) für dieses Objekt, d. h. Ebene zwei. Dies wird bestimmt, indem alle Objekte in der Unit_of_Work_Instance_Object_Table mit Einträgen in Ebene zwei gefunden werden. In diesem Beispiel ist nur Object_A in Ebene zwei vorhanden. Gemäß der Funktion von Rollback wird der Speicher für Object_A in Ebene zwei freigegeben, und Object_A in Ebene eins wird auf aktiv gesetzt. Dadurch wird der Eintrag in der Unit_of_Work_Instance_Object_Table für Object_A in Ebene zwei gelöscht. Nichts geschieht bei Object_B, da dessen aktive Ebene eins ist, d. h. es gibt keinen Eintrag in der Unit_of_Work_Instance_Object_Table in Object_B, Ebene zwei. Rollback subtrahiert dann für dieses Objekt eins von dem Unit_of_Work_Instance_Current_Level. Somit ist die aktuelle Einheit der Arbeitsebene eins. Die Rollback-Routine der Arbeitseinheit kehrt dann zur High-Level-Routine zurück. Datenbank und Speicher können dargestellt werden, wie in Fig. 21 dargestellt.
Die High-Level-Routine gibt dann ein Discard aus, um die Einheit des Arbeitsobjekts zu entfernen. Die Objekte und ihre Attribute einschließlich aller Tabellen werden aus dem Speicher gelöscht. Deshalb bleibt nur die Datenbank wie in Fig. 21 dargestellt. Außerdem bleibt die Datenbank aufgrund der Rollbacks unverändert. Die High-Level-Routine wird dann beendet und schickt die Steuerung an ihren Anforderer zurück.

BEISPIEL 3--ROLLBACK-COMMIT

In einem dritten Beispiel werden Object_A und Object_B in zwei Arbeitseinheiten geändert, wobei eines im anderen innerhalb einer Einheit des Arbeitsobjekts verschachtelt ist. Zum Zweck dieser Darstellung wird die innere Einheit der Arbeitsebene einen Fehler erfahren und mit einem Rollback abschließen. Die äußere Ebene wird erfolgreich abgeschlossen und mit Commit beendet. Dieses Beispiel ist graphisch in Fig. 22 dargestellt.
Der Erstellung von Rahmen ist gleich wie in den Beispielen 1 und 2 - siehe die Abbildung in den Fig. 14-16. Deshalb wird diese hier nicht dupliziert. Sobald die Rahmenebenen erstellt wurden, können sie abgebildet werden - wie Fig. 16 zeigt.
Die High-Level-Routine bestimmt, daß die Einheit der Arbeitsebene drei nicht zufriedenstellend abgeschlossen wurde. Es ist zu beachten, daß der Abschluß als nicht zufriedenstellend angenommen wurde, um Rollback darzustellen. Deshalb ruft die High- Level-Routine das Rollback-Verfahren der Arbeitseinheit auf. Das Rollback-Verfahren der Arbeitseinheit findet alle Datenobjekte, die in der aktuellen Einheit der Arbeitsebene (Unit_of_Work_Instance_Current_Level), d. h. Ebene drei, vorhanden sind. Dies wird bestimmt, indem alle Objekte mit Einträgen in der Unit_of_Work_Instance_Object_Table in Ebene 3 gefunden werden. Wie in Fig. 16 dargestellt, haben sowohl Object_A als auch Object_B Ebenenanzeiger der Arbeitseinheit, die auf drei stehen. Alle Datenobjekte in der Ebene unter der aktuellen Ebene für jedes Objekt werden ihren Status behalten. Alle Datenobjekte in der aktuell aktiven Ebene werden gelöscht. Dies geschieht, indem alle Einträge in der Unit_of_Work_Instance_Object_Table in Ebene 3 gelöscht werden. Die Unit_of_Work_Instance_Current_Level für dieses Objekt wird um eins dekrementiert. Da Object_A eine Kopie im Speicher in der Einheit der Arbeitsebene zwei hat, gibt das Rollback-Verfahren der Arbeitseinheit den Speicher für Object_A in Ebene drei frei, und erstellt Object_A in Ebene zwei als aktuell "aktiv". Da Object_B keine Kopie im Speicher in der Einheit der Arbeitsebene zwei hat, gibt das Rollback-Verfahren der Arbeitseinheit den Speicher für Object_B in Ebene drei frei, und erstellt Object_B in Ebene eins als aktuell "aktiv". Es ist zu beachten, daß nichts in Ebene zwei für Object_B geschieht, weil Object_B in Ebene zwei nicht vorhanden ist.
Rollback subtrahiert für dieses Objekt eins von dem Unit_of_Work_Instance_Current_Level. Die aktuelle Einheit der Arbeitsobjektebene ist jetzt zwei. Das Rollback-Verfahren der Arbeitseinheit schickt die Steuerung an das High-Level-Verfahren zurück. Datenbank und Speicher können dargestellt werden, wie in Fig. 23 abgebildet.
Die High-Level-Routine bestimmt, daß die Einheit der Arbeitsebene zwei zufriedenstellend abgeschlossen wurde und ruft das Commit-Verfahren der Arbeitseinheit auf. Dies wird angenommen, um Commit darzustellen. Die Commit-Routine der Arbeitseinheit findet alle Datenobjekte, die in der aktuellen Einheit der Arbeitsebene (Unit_of_Work_Instance_Current_Level), d. h. Ebene zwei für dieses Objekt, vorhanden sind. Dies geschieht, indem alle Objekte mit Einträgen in der Unit_of_Work_Instance_Object_Table in Ebene zwei gefunden werden. Das die aktuell aktive Ebene zwei ist, erscheint nur Object_A in Ebene zwei. Wenn die aktuell aktive Ebene zwei ist, wird Commit versuchen, die Datenbank zu aktualisieren. Das Commit-Verfahren der Arbeitseinheit wird versuchen, die Datenbank mit den neuen Daten zu aktualisieren, die in Object_A gefunden wurden. Das Verfahren gibt dann einen Befehl in der entsprechenden Datenbankabfragesprache aus, so daß die Änderungen physisch in der Datenbank angelegt werden. Zum Zwecke dieses Beispiels wird angenommen, daß die Datenbankaktualisierungen erfolgreich sind.
Das Commit-Verfahren der Arbeitseinheit wird Object_A in Ebene zwei über Object_A in Ebene eins kopieren, den Speicher für Object_A in Ebene eins freigeben und Ebene eins für Object_A als aktuell aktiv erstellen. Dies geschieht, indem der Eintrag in der Unit_of_Work_Instance_Object_Table in Object_A; Ebene 1 durch den aus Object_A, Ebene 2, ersetzt wird. Die Commit-Routine der Arbeitseinheit subtrahiert für dieses Objekt eins von dem Unit_of_Work_Instance_Current_Level. Dieser Zähler ist jetzt gleich eins. Die Commit-Routine der Arbeitseinheit schickt dann die Steuerung an die High-Level-Routine zurück. Datenbank und Speicher können dargestellt werden, wie in Fig. 24 abgebildet.
Die High-Level-Routine gibt dann ein Discard aus, um die Einheit des Arbeitsobjekts zu entfernen. Dadurch wird die Identifikation von Object_A und Object_B aus der Objektidentifikationstabelle im Speicher gelöscht. Die Objekte, nämlich Object_A und Object_B, in Ebene eins werden ebenfalls aus dem Speicher entfernt. Die Unit_of_Work_Instance_Object_Table wird gelöscht. Die Datenbank bleibt wie in Fig. 24 dargestellt - aktualisiert. Die High-Level-Routine wird dann beendet und schickt die Steuerung an den Anforderer zurück.

BEISPIEL 4--COMMIT-ROLLBACK

In einem vierten Beispiel werden Object_A und Object_B in zwei Arbeitseinheiten geändert, wobei eines im anderen innerhalb einer Einheit des Arbeitsobjekts verschachtelt ist. Zum Zweck der Darstellung wird die innerste Arbeitseinheit erfolgreich abgeschlossen und mit Commit beendet. Die äußerste Einheit kann nicht erfolgreich abgeschlossen werden und muß deshalb mit Rollback abgeschlossen werden. Dieses Beispiel ist in Fig. 25 dargestellt.
Der Erstellung von Rahmen ist gleich wie in den Beispielen 1 und 2 - siehe die Abbildung in den Fig. 14-16. Deshalb wird diese hier nicht dupliziert. Sobald die Rahmenebenen erstellt wurden, können sie abgebildet werden - wie Fig. 16 zeigt.
Die High-Level-Routine bestimmt, daß die Einheit der Arbeitsebene drei zufriedenstellend abgeschlossen wurde. Zum Zwecke der Darstellung wurde zufriedenstellende Abschluß angenommen. Das Commit-Verfahren der Arbeitseinheit wird aufgerufen. Das Commit-Verfahren der Arbeitseinheit findet alle Datenobjekte, die in der Unit_of_Work_Instance_Current_Level, d. h. Ebene 3, vorlhanden sind. Dies geschieht, indem alle Objekte mit Einträgen in der Unit_of_Work_Instance_Object_Table in Ebene 3 gefunden werden. Da der aktuelle Ebenenzähler drei ist, werden sowohl Object_A als auch Object_B gefunden. Commit kopiert die Objekte, die sich in der aktuellen Ebene in der Ebene befinden, die unter der aktuellen Ebene liegt.
Das Commit-Verfahren der Arbeitseinheit kopiert Object_A in Ebene drei über Object_A in Ebene zwei. Commit gibt dann den Speicher für Object_A in Ebene drei frei, und erstellt Object_A in Ebene zwei als aktuell "aktiv". Dies geschieht, indem der Eintrag in der Unit_of_Work_Instance_Object_Table in Object_A, Ebene 2 durch den in Object_A, Ebene 3 ersetzt und der in Ob ject_A, Ebene 3, gelöscht wird. Da Object_B keine Kopie im Speicher in der Einheit der Arbeitsebene zwei hat, setzt Commit die aktive Ebene der Arbeitseinheit auf zwei. Anders ausgedrückt, es kopiert Object_B in Ebene drei in Ebene zwei, indem nur der Ebenenanzeiger für Object_B in Ebene zwei auf zwei gesetzt wird. Dies geschieht, indem die Inhalte der Unit_of_Work_Instance_Object_Table in Object_B, Ebene 2 gleich denen in Object_B, Ebene 3 gesetzt werden, und die in Object_B, Ebene 3 gelöscht werden. Die Commit-Routine der Arbeitseinheit subtrahiert eins von dem Unit_of_Work_Instance_Current_Level. Da die Ebene drei war, ist sie jetzt zwei. Die Commit-Routine der Arbeitseinheit schickt die Steuerung an die High-Level-Routine zurück. Datenbank und Speicher können dargestellt werden, wie in Fig. 26 abgebildet.
Die Ergebnisse dieses Kopiervorgangs können auf alternative Art und Weise erzielt werden. Das gleiche Ergebnis wird erreicht, indem der Zeiger für Object_A in Ebene drei auf den Wert des Zeigers für Object_A in Ebene zwei gestellt wird, d. h. zeigt auf Object_A in Ebene eins. Der Ebenenzähler für Object_B in Ebene drei wird auf Ebene zwei geändert. Der Speicher für Object_A und seine Attribute in Ebene zwei wird freigegeben.
Die High-Level-Routine bestimmt, daß die Einheit der Arbeitsebene zwei nicht zufriedenstellend abgeschlossen wurde und ruft das Rollback-Verfahren der Arbeitseinheit auf. Dies wurde zum Zweck dieses Beispiels angenommen. Das Rollback-Verfahren der Arbeitseinheit findet alle Datenobjekte, die in dem Unit_of_Work_Instance_Current_Level, d. h. Ebene zwei, für dieses Objekt vorhanden sind. Dies geschieht, indem alle Objekte gefunden werden, die Einträge in Ebene zwei in der Unit_of_Work_Instance_Object_Table haben. Da der aktuelle Ebenenzähler zwei ist, werden sowohl Object_A als auch Object_B in Ebene zwei gefunden.
Das Rollback-Verfahren gibt den Speicher für Object_A und seine Attribute in Ebene zwei frei und erstellt Object_A in Ebene eins als aktiv. Rollback gibt auch den Speicher für Object_B und seine Attribute in Ebene zwei frei und erstellt Object_B in Ebene eins aktiv. Dies geschieht, indem die Einträge für Object_A und Object_B in Ebene zwei in der Unit_of_Work_Instance_Object_Table gelöscht werden. Das Rollbaclc-Verfahren der Arbeitseinheit subtrahiert dann für dieses Objekt eins vom Unit_of_Work_Instance_Current_Level. Da der aktuelle Ebenenzähler zwei war, ist er jetzt eins. Das Rollback- Verfahren der Arbeitseinheit schickt dann die Steuerung an die High-Level-Routine zurück. Datenbank und Speicher können dargestellt werden, wie in Fig. 27 abgebildet.
Die High-Level-Routine gibt dann ein Discard aus, um die aktuell aktive Einheit des Arbeitsobjekts aus dem Speicher zu entfernen. Alle Einträge in der Objektidentifikationstabelle einschließlich der Objektidentifikationsnummern und der zugehörigen Adressen, die sich auf dieses aktuell aktive Objekt für Object A und Object_B beziehen, werden gelöscht. Die Unit_of_Work_Instance_Object_Table für die Einheit des Arbeitsobjekts wird ebenfalls gelöscht. Diese bestimmte Einheit des Arbeitsobjekts wird, wenn es ein Objekt selbst ist, aus der Liste der Objekte in der Original-Objektliste der Arbeitseinheit gelöscht, d. h. aus der Objektliste der aufrufenden Arbeitseinheit (Stamm).
Als ein Ergebnis dieses Beispiels bleibt die Datenbank unverändert und kann dargestellt werden, wie in Fig. 27 abgebildet. Es ist zu beachten, daß Object_A und Object_B im Speicher in Ebene eins nach Discard nicht mehr vorhanden sind. Nur die Datenbank ist in diesem Beispiel nach Discard noch vorhanden. Die High-Level-Routine wird dann beendet und schickt die Steuerung an ihren Anforderer.

Claims

1. Ein Objektverwaltungssystem für ein objektorientiertes Rechensystem, das in einem Datenverarbeitungssystem ausgeführt wird, wobei das objektorientierte Rechensystem eine Vielzahl von Datenbankobjekten enthält, die in einem nichtflüchtigen Speicher (14) gespeichert sind und im flüchtigen Speicher (13) verarbeitet werden, wobei jedes Objekt einen Objektrahmen mit Datenattributen und wenigstens ein Objektverfahren zur Durchführung von Aktionen in dem zugehörigen Objekt enthält, wobei die Vielzahl von Datenbankobjekten zusammen in einer Vielzahl von Aufgabenschritten verarbeitet wird, und das Objektverwaltungssystem enthält:

(A) Eine Einheit der Arbeitsobjektklasse mit

(i) einer Einheit des Arbeitsobjektrahmens mit einer Einheit der aktuellen Arbeitsobjektebene zur Anzeige der aktuellen Einheit der Arbeitsebene und

einer Einheit der Arbeitsobjekttabelle, die für jede Einheit der Arbeitsebene Zeiger auf Kopien von diesen Datenbankobjekten enthält, die zusammen verarbeitet werden;

(ii) einem ersten Verfahren (new) zur Erstellung eines Objekts von der Einheit der Arbeitsobjektklasse, um diese aktuelle Ebene der aktuellen Arbeitsobjektebene auf eins zu setzen, um diese Datenbankobjekte, die zusammen von dem nichtflüchtigen Speicher verarbeitet werden, zu laden, und um die entsprechenden Zeiger in dieser Einheit der Arbeitsobjekttabelle zu setzen;

(iii) einem zweiten Verfahren (start), um die Einheit der aktuellen Arbeitsobjektebene um eins zu inkrementieren,

(iv) einem dritten Verfahren (notify), um die Einheit der Arbeitsobjekttabelle zu prüfen, um festzustellen, ob eine Kopie von einem bestimmten Datenbankobjekt unter diesen Objekten, die zusammen in dem flüchtigen Speicher verarbeitet werden, in der aktuellen Einheit der Arbeitsebene vorhanden ist, und falls nicht, um in dem flüchtigen Speicher eine Kopie von dem bestimmten Datenbankobjekt zu erstellen, und um den Zeiger auf die Kopie von diesem bestimmten Datenbankobjekt für die aktuelle Einheit der Arbeitsebene in dieser Einheit der Arbeitsobjekttabelle zu setzen;

(v) einem vierten Verfahren (commit), das angewendet wird, wenn die aktuelle Einheit der Arbeitsebene nicht eins ist, wobei die Änderungen, die in der aktuellen Einheit der Arbeitsebene bei der vorhergehenden Einheit der Arbeitsebene erfolgten, indem die Kopien der Datenbankobjekte von der vorhergehenden Einheit der Arbeitsebene aus dem flüchtigen Speicher entfernt wurden und die Einheit der Arbeitsobjekttabelle aktualisiert wird, um die Zeiger der vorhergehenden Einheit der Arbeitsebene durch Zeiger der aktuellen Einheit der Arbeitsebene zu ersetzen, und die Einheit der aktuellen Arbeitsobjektebene um eins zu dekrementieren, und um diese Datenbankobjekte, die zusammen von dem flüchtigen Speicher im nichtflüchtigen Speicher verarbeitet werden, zu speichern, wenn die aktuelle Einheit der Arbeitsebene eins ist;

(vi) einem fünften Verfahren (rollback), um die Änderungen, die in der aktuellen Einheit der Arbeitsebene erfolgten, zu löschen, indem die Kopien der Datenbankobjekte von der aktuellen Einheit der Arbeitsebene aus dem flüchtigen Speicher gelöscht werden, indem von der Einheit der Arbeitsobjekttabelle Zeiger der aktuellen Einheit der Arbeitsebene gelöscht werden, und die Einheit der aktuellen Arbeitsobjektebene um eins dekrementiert wird; und

(vii) einem sechsten Verfahren (discard), um eine Einheit des Arbeitsobjekts aus dem nichtflüchtigen Speicher zu löschen;

(B) Mittel, die auf eine Anforderung reagieren, die ausgewählten Einsen aus der Vielzahl von Datenbankobjekten zusammen zu verarbeiten, indem das erste Verfahren (new) aufgerufen wird, um ein Objekt aus dieser Einheit der Arbeitsobjektklasse in der Einheit der Arbeitsobjektklasse zu erstellen, und die ausgewählten Objekte im nichtflüchtigen Speicher gespeichert werden, nachdem diese durch Aufruf des vierten Verfahrens (commit) in dem Objekt aus der Einheit der Arbeitsobjektklasse verarbeitet wurden, und

Mittel, die auf eine Aufforderung reagieren, um ein Datenbankobjekt zu ändern, indem das dritte Verfahren (notify) aufgerufen und bei diesem Objekt angewendet wird;

Mittel, die auf den Abschluß eines ersten Schritts aus dieser Vielzahl von Schritten bei den ausgewählten Objekten reagieren, indem eine Kopie von den ausgewählten Objekten im flüchtigen Speicher erstellt wird, wobei die Bedingung von dem ersten Schritt verändert wird, indem das zweite Verfahren (start) vor dem dritten Verfahren (notify) aufgerufen wird, so daß der zweite Schritt in der Kopie mit den ausgewählten Objekten im nichtflüchtigen Speicher durchgeführt wird;

Mittel, die auf den unbefriedigenden Abschluß eines Schritts auf den Aufruf des fünften Verfahrens (rollback) anstatt auf den Aufruf des vierten Verfahrens (commit) reagieren;

Mittel, die auf den Abschluß des vierten Verfahrens (commit) oder das fünfte Verfahren (rollback) reagieren, das auf die Einheit der Arbeitsebene eins angewendet wird, um das sechste Verfahren (discard) aufzurufen.

2. Ein objektorientiertes Rechensystem mit

Datenverarbeitungsmitteln;

nichtflüchtigen Speichermitteln, die mit den Datenverarbeitungsmitteln verbunden sind;

flüchtigen Speichermitteln, die mit der Datenverarbeitung verbunden sind;

einer Vielzahl von Datenbankobjekten, die in den nichtflüchtigen Speichermitteln gespeichert sind, und die in dem Rahmen verarbeitet werden, der Datenattribute enthält und wenigstens ein Objektverfahren, um Aktionen in dem zugehörigen Objekt durchzuführen;

dem Objektverwaltungssystem aus Anspruch 1.

3. Ein Objektverwaltungsprozeß für ein objektorientiertes Rechensystem, das in einem Datenverarbeitungssystem ausge führt wird, wobei das objektorientierte Rechensystem eine Vielzahl von Datenbankobjekten enthält, die in einem nichtflüchtigen Speicher gespeichert sind und im flüchtigen Speicher verarbeitet werden, wobei jedes Objekt einen Objektrahmen mit Datenattributen und wenigstens ein Objektverfahren zur Durchführung von Aktionen in dem zugehörigen Objekt enthält, wobei die Vielzahl von Datenbankobjekten zusammen in einer Vielzahl von Aufgabenschritten verarbeitet wird, und das Objektverwaltungssystem Schritte zur Bereitstellung

einer Einheit der Arbeitsobjektklasse enthält, einschließlich

(i) einer Einheit des Arbeitsobjektrahmens mit einer Einheit der aktuellen Arbeitsobjektebene zur Anzeige der aktuellen Einheit der Arbeitsebene und einer Einheit der Arbeitsobjekttabelle, die für jede Einheit der Arbeitsebene Zeiger auf Kopien von diesen Datenbankobjekten enthält, die zusammen verarbeitet werden;

Aufruf des ersten Verfahrens (new), das auf eine Anforderung reagiert, die ausgewählten Einsen aus der Vielzahl von Datenbankobjekten zusammen zu verarbeiten, indem ein Objekt aus dieser Einheit der Arbeitsobjektklasse in der Einheit der Arbeitsobjektklasse erstellt wird, und

Aufruf des vierten Verfahrens (commit) in dem Objekt von dieser Einheit der Arbeitsobjektklasse, um diese ausgewählten Objekte im nichtflüchtigen Speicher nach Verarbeitung zu speichern, und

Aufruf des dritten Verfahrens (notify), das auf eine Anforderung reagiert, ein Datenbankobjekt zu ändern und es auf dieses Objekt anzuwenden;

Aufruf des zweiten Verfahrens (start), bevor das dritte Verfahren (notify) aufgerufen wird, das auf den Abschluß eines ersten Schritts aus der Vielzahl der Schritte in den ausgewählten Objekten reagiert, um eine Kopie der ausgewählten Objekte im flüchtigen Speicher zu erstellen, wobei die Bedingung aus dem ersten Schritt geändert wurde, so daß der zweite Schritt in der Kopie der ausgewählten Objekte im nichtflüchtigen Speicher durchgeführt wird;

Aufruf des fünften Verfahrens (rollback) anstatt Aufruf des vierten Verfahrens (commit) als Reaktion auf den unbefriedigenden Abschluß eines Schritts;

Aufruf des sechsten Verfahrens (discard) als Reaktion auf den Abschluß des vierten Verfahrens (commit) oder des fünften Verfahrens (rollback), das auf die Einheit der Arbeitsebene eins angewendet wird.