DE4420451A1 - Sperrmechanismus für ein CHECK-IN/CHECK-OUT-Modell - Google Patents

Description

Die Erfindung bezieht sich im allgemeinen auf Sperrmechanismen, insbesondere auf einen Sperrmechanismus für ein CHECK-IN/CHECK-OUT-Modell.

Neuere Informationsverarbeitungssysteme wie beispielsweise Workstations mit einem Server und mehreren Clients, besitzen ein System zum Ausführen von Übertragungsvorgängen, in dem auf die Daten einer gemeinschaftlichen Datenbank zugegriffen wird. In diesem Fall kann der Übertragungsvorgang von der Datenbank eines Servers mit hoher Geschwindigkeit abhängig von einer Anfrage eines Clients durchgeführt werden, wenn die Übertragungseinheit kurz ist, wie z. B. im Falle eines on-line-Systems von Banken.

Die Länge und die Verwendungsart der Übertragungen von beispielsweise CAD (computer aided design)- und CASE (computer aided software environment)-Systemen unterscheiden sich von den Übertragungen der on-line Systeme der Banken. Es ist jedoch wünschenswert, die Datenbank als Datenspeicher auf dem Gebiet der Entwicklung, wie beispielsweise bei CAD und CASE, zu verwenden. Aus diesem Grunde wurden in Dateisystemen, die die Zusammenarbeit mehrerer Personen unterstützen, wie beispielsweise eine Entwicklungsarbeit, an der mehrere Entwicklungsingenieure gleichzeitig beschäftigt sind, zusätzlich zu dem gebräuchlichen CHECK-IN/CHECK-OUT-Modell eine Datenbank eingesetzt. Mithilfe der in ein derartiges Dateisystem eingeführten Datenbank können die damit verbundenen Vorteile der Verarbeitungsfunktionen o. ä. ausgenützt werden, wie beispielsweise Pflege der Übertragung, Bereitstellung eines qualitativen Datenmodells und die Möglichkeit der Datenwiederbeschaffung.

Durch die Verbindung des CHECK-IN/CHECK-OUT-Modells mit der Datenbank treten jedoch aufgrund der Natur der Übertragungen Probleme abhängig von den Übertragungen in dem jeweiligen Technikgebiet auf. So kann beispielsweise ein Editiervorgang eine längere Zeit benötigen und der Vorgang kann interaktive Operationen einschließen. Es ist daher erforderlich, diese Probleme zu lösen.

Fig. 1 zeigt den beispielhaften Aufbau eines herkömmlichen Übertragungsmodells und Fig. 2 zeigt den beispielhaften Aufbau eines herkömmlichen CHECK-IN/CHECK- OUT-Modells.

In Fig. 1 sind ein Client A, ein Client B und ein Server S jeweils auf unabhängige Workstations aufgeteilt. Mit dem Server S ist eine öffentliche Datenbank DB verbunden, die von den Clients A und B gemeinsam benutzt wird. So können beispielsweise auf der öffentlichen Datenbank DB Kontodaten einer Bank gespeichert sein und der Server S befindet sich auf derjenigen Workstation, die die Kontodaten verarbeitet. Zusätzlich befinden sich die Clients A und B jeweils auf denjenigen Workstations (oder Terminals), die über eine on-line Verbindung an den Server S angeschlossen sind. Wird von dem Client A oder B eine Anfrage ausgegeben, um auf den Inhalt der öffentlichen Datenbank DB zuzugreifen oder diesen zu erneuern, so führt der Server S aufgrund der zuvor beschriebenen Anordnung den Übertragungsvorgang abhängig von dieser Anfrage aus. In diesem Fall sind die Daten der durchgeführten Übertragung kurz und die Übertragung kann sehr schnell durchgeführt werden. Zusätzlich werden die Übertragungen in der Reihenfolge ihres Auftretens ausgeführt.

Demzufolge wird der Client B bereits die erneuerten Daten empfangen, wenn der Client B auf den Inhalt der öffentlichen Datenbank DB zugreifen will, nachdem der Inhalt der öffentlichen Datenbank DB durch den von dem anderen Client A angeforderten Übertragungsvorgang erneuert worden ist. Die Daten werden in Übereinstimmung mit den im Laufe der Zeit auftretenden Übertragungen erzeugt und die Datenkonsistenz ist gewährleistet.

Würde das in Fig. 1 gezeigte Übertragungsmodell auf ein Entwicklungsgebiet, wie beispielsweise CAD oder CASE, angewendet werden, so wird die öffentliche Datenbank DB abhängig von der Art der Entwicklungsarbeit für eine längere Zeit im Rahmen von mehreren Stunden oder mehreren Tagen ausschließlich von einem Client benutzt, wobei die öffentliche Datenbank DB dialogartig genutzt wird. Aufgrund der ausschließlichen Nutzung der Daten für eine längere Zeit verschlechtert sich die Leistungsfähigkeit des Übertragungsmodells und die Arbeit wird für lange Zeit unterbrochen, wenn eine Blockade auftritt. Daher wurde das CHECK-IN/CHECK-OUT-Modell vorgeschlagen, um diese Probleme des Übertragungsmodells zu beseitigen.

Ähnlich zu dem in Fig. 1 dargestellten Übertragungsmodell ist bei dem in Fig. 2 gezeigten CHECK-IN/CHECK-OUT-Modell die öffentliche Datenbank DB mit dem Server S verbunden. Allerdings sind in Fig. 2 private Datenbanken PDB1 und PDB2 jeweils für die Clients A und B vorhanden. Der Benutzer des Clients A besitzt das Zugriffsrecht auf die private Datenbank PDB1 und der Benutzer des Clients B besitzt das Zugriffsrecht auf die private Datenbank PDB2. Das Zugriffsrecht auf die öffentliche Datenbank DB besitzen die Benutzer aller Clients, d. h. in diesem Fall die Benutzer der Clients A und B. Somit wird die öffentliche Datenbank DB gemeinsam durch die Clients A und B benutzt.

Falls der Benutzer des Clients A die öffentliche Datenbank DB für einen Editiervorgang o. ä. benutzt, fordert der Client A eine Kopie der notwendigen Daten von dem Server S an. Infolge dieser Anfrage liest der Server S die notwendigen Daten aus der öffentlichen Datenbank DB aus und sendet die entsprechenden Daten an den Client. Der Client A kopiert die empfangenen notwendigen Daten in die private Datenbank PDB1. Der zuvor beschriebene Prozeß wird "check-out" genannt. Danach kann der Client A unter Zuhilfenahme der privaten Datenbank PDB1, die die notwendigen kopierten Daten gespeichert hält, die Daten dialogartig für längere Zeit bearbeiten, z. B. editieren. Auf ähnliche Weise kann auch der Client B über den Server S mittels des check-out- Vorganges die notwendigen Daten aus der öffentlichen Datenbank DB in die private Datenbank PDB2 kopieren und mit diesen Daten für lange Zeit unter Zuhilfenahme der privaten Datenbank PDB2 arbeiten.

Andererseits werden die Daten der privaten Datenbank PDB1 über den Server S an die öffentliche Datenbank DB zurückgegeben, wenn der Client A die Verarbeitungsvorgänge bezüglich des Inhalts der privaten Datenbank PDB1 beendet hat, beispielsweise das Editieren, so daß der Inhalt der öffentlichen Datenbank DB erneuert wird. Dieser Vorgang, wenn Daten von der privaten Datenbank PDB1 des Clients A erhalten werden und diese Daten an die öffentliche Datenbank DB über den Server S zurückgegeben werden, wird "check-in" genannt.

Um in dem in Fig. 1 gezeigten Übertragungsmodell Datenkonsistenz der Datenbank zu gewährleisten, wird ein zweistufiger Sperrmechanismus angewendet. Die Konsistenz der Daten (oder deren Weiterbehandlungsmöglichkeit) wird beibehalten, wenn gewährleistet ist, daß der Inhalt der Datenbank in derselben Reihenfolge verändert wird, in der die Übertragungen erzeugt werden. Die Konsistenz der Daten kann nicht beibehalten werden, wenn eine doppelte Erneuerung stattfindet, bei der ein Übertragungsvorgang in Bezug auf Daten D erzeugt wird, während im Laufe einer anderen Übertragung ein Erneuerungsprozeß der Daten D zu Daten D′ ausgeführt wird. Bei einem Fehler kommt es zum Verlust der Erneuerung. Die Konsistenz der Daten kann jedoch beibehalten werden, wenn gewährleistet ist, daß der Inhalt der Datenbank in der Reihenfolge verändert wird, in der die Übertragungen erzeugt werden.

Dem herkömmlichen zweistufigen Sperrmechanismus entsprechend sperrt die eine Phase innerhalb einer Übertragung die Daten und die andere Phase gibt diese Daten wieder frei, um die anderen Übertragungen abzublocken.

Andererseits dauert es bei dem in Fig. 2 gezeigten CHECK-IN/CHECK-OUT-Modell lange Zeit, bis die Daten nach einem check-out-Vorgang verarbeitet werden können, beispielsweise editiert werden können, und es ist praktisch unmöglich, die Konsistenz der Daten wie bei dem in Fig. 1 gezeigten Übertragungsmodell aufrechtzuerhalten. Aus diesem Grund werden Übertragungen und deren Reihenfolge von einem System, das das CHECK-IN/CHECK-OUT-Modell anwendet, nicht verwaltet. Anstatt die Konsistenz der Daten basierend auf den Übertragungen beizubehalten, erlaubt ein derartiges System, daß die check-out-Phase und die check-in-Phase nicht unabhängig voneinander sind und auch, daß diejenigen Daten, die von einem Benutzer in einem Erneuerungsmodus eingecheckt werden, gleichzeitig von einem anderen Benutzer in einem Zugriffsmodus ausgecheckt werden.

Es wurde gefordert, einem Prozeß, der nur eine kurze Zeit benötigt, und einen langandauernden Prozeß auf dem gleichen System zu realisieren, in dem das in Fig. 2 gezeigte CHECK-IN/CHECK-OUT-Modell mit der bestehenden Datenbank des in Fig. 1 gezeigten Übertragungsmodells verbunden wird. Eine derartige Realisierung würde beispielsweise bei einem CAD-System ermöglichen, daß auf die Datenbank zur Beschaffung der Daten der notwendigen Teile zugegriffen werden kann, wenn mit den von der Datenbank ausgecheckten Entwicklungsdaten eine dialogartige Entwicklung gemacht wird.

Wird das CHECK-IN/CHECK-OUT-Modell mit der bestehenden Datenbank zusammengefügt, so beeinflussen die beiden zweistufigen Sperrmechanismen der bestehenden Datenbank und des CHECK-IN/CHECK-OUT-Modells sich gegenseitig, was zum Verlust der Datenkonsistenz der bestehenden Datenbank führen kann.

Nachfolgend wird unter Bezugnahme auf Fig. 3 beispielhaft beschrieben, wie es zum Verlust der Datenkonsistenz kommen kann, wenn die Übertragung des zweistufigen Sperrmechanismus und das CHECK-IN/CHECK-OUT-Modell einfach miteinander kombiniert werden.

In Fig. 3 bezeichnet LT eine Übertragung des Clients A im CHECK-IN/CHECK- OUT-Modell und ST eine Übertragung des Clients B mit dem zweistufigen Sperrmechanismus. Als Anfangswerte sind in der Datenbank ein Kontostand X und ein Kontostand Y gespeichert, die jeweils 100 Dollar betragen. In diesem Beispiel transferiert die Übertragung LT 20 Dollar von dem Kontostand X zu den Kontostand Y und die Übertragung ST berechnet die Summe der beiden Kontostände.

Zunächst checkt die Übertragung LT den Kontostand X aus und führt die Subtraktion von 20 Dollar aus (so daß X 80 Dollar beträgt). Anschließend checkt die Übertragung LT den Kontostand Y aus und führt die Addition von 20 Dollar durch (so daß Y 120 Dollar beträgt). Danach werden die Kontostände X und Y eingecheckt.

Wenn die Übertragung ST den Zugriffsvorgang (oder Lesevorgang) der Kontostände X und Y und den Additionsvorgang der Kontostände ausführt, wird andererseits das Auslesen des Kontostandes X, das der Eröffnungsübertragung folgt, möglich, nachdem die Übertragung LT den Kontostand X ausgecheckt hat. Dann wird als Kontostand X 100 Dollar ausgelesen.

Anschließend wird das Lesen des Kontostandes Y ermöglicht, wenn die Übertragung LT den Kontostand Y eingecheckt hat, und in diesem Fall wird 120 Dollar als Kontostand Y ausgelesen, da, wie zuvor beschrieben, bereits 20 Dollar zu den Kontostand Y durch die Übertragung LT hinzuaddiert worden sind. Als Ergebnis wird "X+Y=220 Dollar" ausgegeben, wenn ein "Drucke X+Y"-Befehl ausgeführt wird. Dieses Resultat ist falsch, da die richtige Summe der Kontostände X und Y 200 Dollar wäre.

Aufgrund dieses Systems, das Datenfehler erzeugt, werden schwerwiegende Probleme hervorgerufen. Es ist denkbar, dieses Problem zu lösen, indem das CHECK- IN/CHECK-OUT-Modell und den Sperrmechanismus der bestehenden Datenbank angepaßt wird. Wenn jedoch Entwicklungsarbeit durch mehrere Entwicklungsingenieure durchgeführt wird, die sich des CHECK-IN/CHECK-OUT-Modells bedienen, treten oft Fälle auf, bei denen ein Entwicklungsingenieur auf einen Teil eines Planes zugreifen will, der von einem anderen Entwicklungsingenieur gerade verändert wird. Da zusätzlich eine derartige Veränderungsarbeit o. ä. gewöhnlich eine lange Zeit benötigen, ist dies sehr problematisch, da in der Praxis nicht derartig lange gewartet werden kann, bis die Veränderung beendet worden ist.

Es ist daher Aufgabe der Erfindung, einen neuen und nützlichen Sperrmechanismus bereitzustellen, mit dessen Hilfe die zuvor beschriebenen Probleme beseitigt werden.

Desweiteren soll ein Sperrmechanismus für ein CHECK-IN/CHECK-OUT-Modell bereitgestellt werden, der basierend auf Übertragungen einer bestehenden Datenbank Datenkonsistenz gewährleistet und eine Verringerung der Leistungsfähigkeit verhindert, die durch eine ausschließliche Nutzung der Daten für eine lange Zeit in dem CHECK- IN/CHECK-OUT-Modell verursacht wird.

Schließlich soll ein Sperrmechanismus für ein CHECK-IN/CHECK-OUT-Modell geschaffen werden, bei dem mehrere Clients auf die öffentliche Datenbank eines Servers zugreifen, umfassend eine in dem Server vorhandene Verwaltungsvorrichtung für lange Übertragungen zur Verwaltung von Übertragungen, die von dem Client angefordert werden, mit einem CHECK-OUT-Vorgang, der Daten von der öffentlichen Datenbank kopiert, und einen CHECK-OUT-Vorgang, der Daten zurück in die öffentliche Datenbank schreibt, eine in dem Server vorhandene Verwaltungsvorrichtung für kurze Übertragungen zur Verwaltung von Übertragungen, die keine Daten von der öffentlichen Datenbank kopieren, und eine Übertragungsliste zur Speicherung von Informationen, die den Inhalt der Übertragungen angeben, die sowohl durch die Verwaltungsvorrichtung für lange Übertragungen als auch durch die Verwaltungsvorrichtung für kurze Übertragungen durchgeführt worden sind, wobei die Verwaltungsvorrichtung für lange Übertragungen eine Einrichtung beinhaltet, die das Einchecken willkürlicher Daten aufschiebt, bis eine andere Übertragung, die auf die willkürlichen Daten zugreift, beendet ist, wenn die andere Übertragung von der Übertragungsliste zwischen dem CHECK-OUT-Vorgang und dem CHECK-OUT- Vorgang erfaßt wird. Es ist gemäß dem erfindungsgemäßem Sperrmechanismus möglich, die Datenkonsistenz des herkömmlichen Übertragungsmodells beizubehalten und das CHECK-IN/CHECK-OUT-Modell dem herkömmlichen Datenbanksystem hinzuzufügen. Zusätzlich ist es für den Benutzer nicht mehr erforderlich, die Datenkonsistenz während des Betriebes aufrechtzuerhalten, wenn der erfindungsgemäße Sperrmechanismus mit dem Sperrmechanismus des CHECK-IN/CHECK-OUT-Modells hinzugefügt wird. D.h. es ist möglich, das herkömmliche Übertragungsmodell und das CHECK-IN/CHECK-OUT-Modell zu integrieren, wobei die Vorteile beider Systeme ohne Einschränkungen miteinander kombiniert werden.

Desweiteren soll ein Server mit einem Sperrmechanismus für ein CHECK-IN/CHECK- OUT-Modell bereitgestellt werden, bei dem einer oder mehrere Clients auf eine öffentliche mit dem Server verbundene Datenbank zugreifen, umfassend eine Verwaltungsvorrichtung für lange Übertragungen zur Verwaltung von Übertragungen, die von dem Client angefordert werden, mit einem CHECK-OUT-Vorgang, der Daten von der öffentlichen Datenbank kopiert, und einem CHECK-OUT-Vorgang, der Daten zurück in die öffentlich Datenbank schreibt, eine Verwaltungsvorrichtung für kurze Übertragungen zur Verwaltung von Übertragungen, die keine Daten von der öffentlichen Datenbank kopieren und eine Übertragungsliste zur Speicherung von Informationen, die den Inhalt der Übertragungen angeben, die durch die Verwaltungsvorrichtung für lange Übertragungen und die Verwaltungsvorrichtung von kurzen Übertragungen durchgeführt worden sind, wobei die Verwaltungsvorrichtung für lange Übertragungen eine Einrichtung beinhaltet, die das Einchecken von willkürlichen Daten aufschiebt, bis eine andere Übertragung, die auf die willkürlichen Daten zugreift, beendet ist, wenn die andere Übertragung von der Übertragungsliste zwischen dem CHECK-OUT-Vorgang und dem CHECK-OUT-Vorgang erfaßt ist. Mit dem erfindungsgemäßen Server ist es möglich, die Datenkonsistenz des herkömmlichen Übertragungsmodells aufrechtzuerhalten und das CHECK-IN/CHECK-OUT-Modell kann in das herkömmliche Datenbanksystem eingefügt werden. Zusätzlich ist es für die Benutzer nicht mehr erforderlich, die Datenkonsistenz während des Betriebes aufrechtzuerhalten, wenn der erfindungsgemäße Sperrmechanismus mit dem Sperrmechanismus des CHECK-IN/CHECK-OUT-Modells kombiniert wird. D.h. es ist möglich, das herkömmliche Übertragungsmodell und das CHECK-IN/CHECK-OUT- Modell miteinander zu kombinieren, wobei die jeweiligen Vorteile ohne Einschränkungen bestehen bleiben.

Die Erfindung wird nachfolgend unter Bezugnahme auf die Zeichnung näher beschrieben. Es zeigt:

Fig. 1 ein systematisches Blockdiagramm eines beispielhaften Aufbaus eines herkömmlichen Übertragungsmodells,

Fig. 2 ein systematisches Blockdiagramm eines beispielhaften Aufbaus eines herkömmlichen CHECK-IN/CHECK-OUT-Modells,

Fig. 3 ein Diagramm zur Erläuterung eines besonderen Beispiels des Verlustes der Datenkonsistenz, wenn eine Übertragung mit einem zweistufigen Sperrmechanismus und das CHECK-IN/CHECK-OUT-Modell einfach miteinander kombiniert werden,

Fig. 4. ein systematisches Blockdiagramm zur Erläuterung der Funktionsweise der Erfindung,

Fig. 5 ein systematisches Blockdiagramm eines Ausführungsbeispieles eines erfindungsgemäßen Sperrmechanismus,

Fig. 6 ein Flußdiagramm zur Erläuterung der Funktionsweise des Sperrmechanismus- Ausführungsbeispieles,

Fig. 7 ein Flußdiagramm zur Erläuterung der Funktionsweise eines in Fig. 5 dargestellten Übertragungs-Verwaltungsteils und

Fig. 8 ein Diagramm zur Erläuterung der durch die Erfindung gewährten Datenkonsistenz.

Nachfolgend wird zunächst unter Bezugnahme auf Fig. 4 die Funktionsweise der Erfindung beschrieben.

Fig. 4 zeigt einen Server 1, der eine öffentliche Datenbank 8 mit einem Client 9 verbindet. Der Server 1 umfaßt ein Verwaltungsteil 2 für lange Übertragungen und ein Verwaltungsteil 5 für kurze Übertragungen sowie eine Übertragungsliste 7. Das Verwaltungsteil 2 für lange Übertragungen beinhaltet ein CHECK-OUT-Teil 3 und ein CHECK-IN-Teil 4. Das Verwaltungsteil 5 für kurze Übertragungen beinhaltet ein Zugriffsteil 6. Die Übertragungsliste 7 beinhaltet eine Erneuerungsliste 7a und eine Zugriffsliste 7b.

Erfindungsgemäß wird ein Zeitintervall zwischen dem CHECK-OUT-Vorgang und dem CHECK-OUT-Vorgang als eine lange Übertragung betrachtet und die Übertragung selbst umfaßt zwei Phasen. Eine erste Übertragungsphase umfaßt lediglich das Auschecken der Daten und eine zweite Übertragungsphase umfaßt lediglich das Einchecken der Daten. Der Server 1 ermittelt die Phase für jede lange Übertragung. Werden die Daten nach einem CHECK-OUT-Vorgang wieder eingecheckt, so überwacht der Server 1 die CHECK-IN-Zeit abhängig davon, ob andere Übertragungen auf dieselben Daten zugreifen, um die Datenkonsistenz aufrechtzuerhalten.

Wenn der Client 9 im Erneuerungsmodus das Ausschecken von Daten anfordert, bestimmt das Verwaltungsteil 2 für lange Übertragungen des Servers 1, daß dieser CHECK-OUT-Vorgang in zwei Phasen aufgeteilt wird. Zusätzlich eröffnet das Verwaltungsteil 2 für lange Übertragungen die lange Übertragung und startet das CHECK-OUT-Teil 3, wenn die Anfrage gültig ist. Das CHECK-OUT-Teil 3 dient zum Auschecken der angeforderten Daten. D.h. das CHECK-OUT-Teil 3 liest die angeforderten Daten von der öffentlichen Datenbank 8 aus und kopiert die ausgelesenen und angeforderten Daten zu dem Client 9. Zu diesem Zeitpunkt wird eine Übertragungsidentifikation (ID oder ID-Nummer) der langen Übertragung, eine Daten- Identifikation und ein Übertragungsstatus in der Erneuerungsliste 7a der Übertragungsliste 7 gespeichert. Der Übertragungsstatus gibt den Status der Übertragung an, z. B. "noch aktiv", "beendet" o. ä.

Das Verwaltungsteil 5 für kurze Übertragungen verwaltet die Daten gemäß dem herkömmlichen zweistufigen Sperrmechanismus, d. h. das Sperren der Daten wird seitens der öffentlichen Datenbank 8 verwaltet. Wird eine kurze Übertragung von einem von dem Client 9 abweichenden Client erzeugt, um auf die Daten zugreifen zu können, so bestimmt das Verwaltungsteil 5 für kurze Übertragungen, ob die Daten den in der Erneuerungsliste 7a ausgecheckten Daten entsprechen. Entsprechen die Daten den in der Erneuerungsliste 7a gespeicherten ausgecheckten Daten, so werden die Übertragungsidentifikation, die Datenidentifikation und der Übertragungsstatus in der Zugriffsliste 7b der Übertragungsliste 7 gespeichert. Ist diese kurze Übertragung beendet, so wird die gespeicherte Information aus der Zugriffsliste 7b gelöscht.

Ein Zugriff auf die Daten ist möglich, wenn der Client das Auschecken der Daten im Zugriffsmodus anfordert und auch wenn das Verwaltungsteil 2 für lange Übertragungen die Übertragung öffnet, so daß die Übertragung durch das CHECK-OUT-Teil 3 ausgeführt wird. In jedem dieser beiden Fälle wird die Bestimmung der Erneuerungsliste 7a und die Speicherung in der Zugriffsliste 7b analog zu dem zuvor beschriebenen ausgeführt.

Beendet der Client 9 die Datenbearbeitung und fordert das Einchecken der Daten an, so bestimmt das CHECK-IN-Teil 4 des Verwaltungsteiles 2 für lange Übertragungen im Server 1, ob der CHECK-OUT-Vorgang in zwei Phasen analog zu dem CHECK-OUT- Vorgang aufgeteilt wird. Ist die Anfrage gültig, so bestimmt das Verwaltungsteil 2 für lange Übertragungen, ob weitere offene Übertragungen existieren, die auf dieselben Daten zugreifen, indem die Zugriffsliste 7b ausgewertet wird. Existiert eine weitere offene Übertragung, so tritt ein Wartezustand auf, bis diese andere offene Übertragung beendet ist. Falls keine weitere offene Übertragung existiert, wird andererseits der CHECK-OUT-Vorgang ausgeführt, um die öffentliche Datenbank 8 zu erneuern. Während des Wartens auf diesen CHECK-OUT-Vorgang wird der Zugriff von anderen Übertragungen auf die ausgecheckten Daten vorübergehend unterbunden.

Wird das Auschecken des CHECK-IN/CHECK-OUT-Modells und der Zugriff der Übertragung bezüglich identischer Daten gleichzeitig erzeugt, so wird entsprechend der Zugriff der Übertragung zwischen dem CHECK-OUT-Vorgang und dem CHECK- OUT-Vorgang zwangsweise vor dem CHECK-OUT-Vorgang ausgeführt, um die Datenkonsistenz zwischen den Übertragungen zu gewährleisten.

Nachfolgend wird ein Ausführungsbeispiel des erfindungsgemäßen Sperrmechanismuss für ein CHECK-IN/CHECK-OUT-Modell beschrieben. Fig. 5 zeigt den Aufbau dieses Sperrmechanismus-Ausführungsbeispieles und Fig. 6 zeigt ein Flußdiagramm zur Verdeutlichung der Funktionsweise dieses Ausführungsbeispieles.

In Fig. 5 ist der clientseitige Teil über der gestrichelten Linie und der serverseitige Teil unter der gestrichelten Linie dargestellt. Auch wenn tatsächlich mehrere Clients mit dem Server verbunden sind, wird in Fig. 5 der Einfachheit halber nur ein Client dargestellt.

Der clientseitige Teil umfaßt eine private Datenbank 20 für die ausschließliche Benutzung durch den Benutzer, einen Speicher 21 zum Puffern von Daten, die in die private Datenbank 20 eingegeben werden und von dieser ausgegeben werden, ein Verwaltungsteil 22 zur Verwaltung der privaten Datenbank, ein Verwaltungsteil 23 zur Verwaltung von kurzen Übertragungen und ein Kommunikationsteil 24 um die Kommunikation zwischen der Client-Seite und der Server-Seite zu steuern.

Die Server-Seite umfaßt ein Kommunikationsteil 25 zur Steuerung der Kommunikation zwischen der Server-Seite und der Client-Seite, ein Übertragungs-Verwaltungsteil 26 zur Verwaltung verschiedenartiger, von der Client-Seite angeforderter Übertragungen, ein Verwaltungsteil 27 zur Verwaltung der öffentlichen Datenbank, einen Speicher 28 zum Puffern von Daten und eine öffentliche Datenbank 29. Das Übertragungs- Verwaltungsteil 26 umfaßt ein Verwaltungsteil 26a für kurze Übertragungen wie z. B. Zugriff und Erneuerung, die nicht einen Kopiervorgang der Daten beinhalten, und ein Verwaltungsteil 26b für lange Übertragungen, das zur Verwaltung von CHECK- IN/CHECK-OUT-artigen Übertragungen dient, die einen Kopiervorgang der Daten beinhalten, sowie eine Übertragungsliste 26c, die eine Erneuerungsliste und eine Zugriffsliste beinhaltet.

Im Falle einer langen Übertragung nutzt die Client-Seite ausschließlich die Daten, nach dem die Daten aus der öffentlichen Datenbank 29 der Server-Seite ausgecheckt und in die private Datenbank 20 der Client-Seite kopiert worden sind. Daher ist es nicht erforderlich, die lange Übertragung auf der Client-Seite zu verwalten. Im Falle eines Multiprozesses werden jedoch mehrere Kurzübertragungen durch den gleichen Benutzer erzeugt und Vorgänge wie z. B. Zugriff auf die öffentliche Datenbank 29 der Server- Seite werden ausgeführt. Aus diesem Grund ist das Verwaltungsteil 23 für kurze Übertragungen auf der Client-Seite vorhanden.

Die Server-Seite kommuniziert mit mehreren Clients über das Kommunikationsteil 25 und das Übertragungs-Verwaltungsteil 26 identifiziert die angeforderte Übertragung. Die kurze Übertragung, wie beispielsweise der Zugriff, der keinen CHECK- IN/CHECK-OUT-Vorgang besitzt, wird durch das Verwaltungsteil 26a für kurze Übertragungen durchgeführt. Andererseits wird die lange Übertragung, wie z. B. der Erneuerungsmodus oder der Zugriffsmodus des CHECK-IN/CHECK-OUT-Modells, durch das Verwaltungsteil 26b für lange Übertragungen durchgeführt.

Während des Betriebes des Verwaltungsteils 26a für kurze Übertragungen und des Verwaltungsteils 26b für lange Übertragungen wird jeweils eine Registrierung in der Übertragungsliste 26c bzw. ein Zugriff auf diese durchgeführt. Die Übertragungsidentifikation, die Datenidentifikation und der Übertragungsstatus werden in der Erneuerungsliste und in der Zugriffsliste der Übertragungsliste 26c gespeichert. Der Übertragungsstatus gibt an, ob die Übertragung weiterhin verarbeitet wird oder die Übertragung bereits beendet ist. Für den Zustand, bei dem die Verarbeitung der Übertragung bereits beendet ist, ist ein Bestätigungsflag vorhanden, um einen Bestätigungszustand anzuzeigen, bei dem die Übertragung ausgeführt wird und die Übertragung auf die Daten zurückgeführt wird, oder es wird ein Abbruchzustand begonnen, bei dem die Übertragung nicht ausgeführt wird und der dem Zustand vor der Übertragung entspricht.

Das Verwaltungsteil 27 zur Verwaltung der öffentlichen Datenbank greift auf die öffentliche Datenbank 29 abhängig von einem Befehl des Übertragungs- Verwaltungsteils 26 zu und verwaltet über den Speicher 28 das Lesen bzw. Schreiben der angeforderten Daten aus der öffentlichen Datenbank bzw. in die öffentliche Datenbank.

Fig. 6 ist ein Flußdiagramm zur Erläuterung der Funktionsweise des in Fig. 5 dargestellten Ausführungsbeispieles.

In Fig. 6 wird in einem Schritt S1 zunächst die notwendigen Daten auf Anfrage der Client-Seite ausgecheckt und die notwendigen Daten von der öffentlichen Datenbank 29 in die private Datenbank 20 kopiert. Im Falle des Auscheckens im Erneuerungsmodus wird eine Erneuerungssperre bezüglich der Daten in der öffentlichen Datenbank 29 veranlaßt. Andererseits wird im Falle eines Auscheckens im Zugriffsmodus eines Zugriffsperre veranlaßt. Somit umfaßt dieser Schritt S1 die Kommunikationsteile 24 und 25 und das Verwaltungsteil 26b für lange Übertragungen.

Anschließend wird in einem Schritt S2 die Identifikation (ID) des Clients, die ID- Nummer der ausgecheckten Daten und das Bestätigungsflag, das den Übertragungszustand angibt, in die Übertragungsliste 26c des Übertragungs- Verwaltungsteils 26 auf der Server-Seite geschrieben. Somit umfaßt der Schritt S2 das Verwaltungsteil 26b für lange Übertragungen und die Übertragungsliste 26c.

Anschließend ist es, selbst wenn ein Zugriff eines anderen Clients auf die ausgecheckten Daten erfolgt und selbst wenn eine Erneuerungssperre bezüglich dieser Daten bereits vollzogen ist, in Schritt S3 möglich, auf die Daten der öffentlichen Datenbank 29 zuzugreifen, die sich im Zustand vor der Erneuerung befindet. Zusätzlich wird dieser Zugriff in der Übertragungsliste 26c auf der Server-Seite registriert, um die Datenkonsistenz aufrechtzuerhalten, wenn dieser Zugriff gemacht wird. Somit umfaßt dieser Schritt S3 das Verwaltungsteil 26a für kurze Übertragungen und die Übertragungsliste 26c.

In Schritt S4 wird ein Flag gesetzt, das den Endzustand in dem Bestätigungsflag der Übertragungsliste 26c bezeichnet, wenn der Bestätigungszustand oder der Abbruchzustand der in der Übertragungsliste 26c registrierten Übertragung auftritt. Wie zuvor beschrieben, bezeichnet der Bestätigungszustand den Zustand, bei dem die Übertragung beendet worden ist und auf die Daten zurückgeführt wird, und der Abbruchzustand bezeichnet den Zustand, bei dem die Übertragung fehlgeschlagen ist und entspricht dem Zustand vor der Übertragung. Somit umfaßt dieser Schritt S4 das Verwaltungsteil 26a für kurze Übertragungen und die Übertragungsliste 26c.

Ist der Editiervorgang in der privaten Datenbank 20 bezüglich der auf der Client-Seite ausgecheckten Daten abgeschlossen, so wird in Schritt S5 von der Client-Seite ein CHECK-OUT-Vorgang der Daten von der Server-Seite angefordert. Somit umfaßt dieser Schritt S5 die Kommunikationsteile 24 und 25.

In diesem Fall wird in einem Schritt S6 die Übertragungsliste 26c in Bezug auf die Daten, die dieselbe Datenidentifikation wie die auszucheckenden Daten (d. h., in der dieselben Daten gespeichert sind) überprüft. Somit umfaßt dieser Schritt S6 das Verwaltungsteil 26b für lange Übertragungen.

In einem Schritt S7 wird festgestellt, ob eine Übertragung existiert, die sich auf dieselben Daten bezieht und die ein Bestätigungsflag aufweist, das sich nicht im Endzustand befindet. Somit umfaßt dieser Schritt S7 das Übertragungs-Verwaltungsteil 26.

Existiert eine derartige Übertragung und ist das Resultat in Schritt S7 JA, so wird in einem Schritt S8 ein Zugriff auf die ausgecheckten Daten unterbunden und der Wartezustand begonnen, um das Ende des CHECK-OUT-Vorganges abzuwarten. Dieser Wartezustand wird aufgehoben, falls die Übertragung den Endzustand erreicht. D.h., daß der Prozeß vom Schritt S7 wieder in Schritt S8 zurückkehrt. Somit umfaßt dieser Schritt S8 das Übertragungs-Verwaltungsteil 26.

Ist jedoch das Ergebnis der Entscheidung in Schritt S7 NEIN, so wird in einem Schritt S9 die CHECK-IN-Anfrage auf der Server-Seite ausgeführt und der Prozeß wird beendet, nachdem die angeforderten Daten in die öffentliche Datenbank 29 eingecheckt worden sind. Somit umfaßt dieser Schritt 29 das Übertragungs-Verwaltungsteil 26.

Im Wartezustand des CHECK-OUT-Vorganges können nachfolgende Datenzugriffe durch andere Übertragungen auftreten und es ist möglich, daß der CHECK-OUT- Vorgang nicht ausgeführt werden kann. Daher wird der Schritt S8 ausgeführt, um mit einer derartigen Situation fertigzuwerden. D.h., daß in dem Wartezustand des CHECK- OUT-Vorganges der Zugriff auf die durch den CHECK-OUT-Vorgang erhaltenen Daten, die die Voraussetzung für den CHECK-OUT-Vorgang der anderen Übertragungen sind, unterbunden wird. In diesem Fall ist die Wartezeit der durch die zuvor beschriebene Kurzübertragung verursachte Blockade vernachlässigbar, wenn die für den CHECK-OUT-Vorgang und den CHECK-OUT-Vorgang benötigte lange Zeit mit der für die Übertragung, z. B. bei einem gewöhnlichen Zugriff, benötigte kurze Zeit verglichen wird. Die lange Übertragung, die die im Erneuerungsmodus ausgecheckten Daten ausschließlich nutzt, kann warten, bis die lange Übertragung, die dieselben Daten im Zugriffsmodus auscheckt, beendet ist, und es ist daher möglich, daß die Leistungsfähigkeit verringert wird. Es ist jedoch möglich, die Wartezeit durch Ausnutzen der Nachrichtenfunktion zu verringern. Zusätzlich wird die kurze Übertragung nicht auf die lange Übertragung warten, da die kurze Übertragung durch den grundlegenden zweistufigen Sperrmechanismus verwaltet wird.

Fig. 7 ist ein Zeitdiagramm zur Erläuterung der Funktionsweise des Übertragungs- Verwaltungsteils 26, insbesondere zur Erläuterung der Funktionsweise des Verwaltungsteils 26b zur Verwaltung langer Übertragungen in diesem Falle.

In Fig. 7 wird in einem Schritt T1 die erste CHECK-IN- oder CHECK-OUT-Anfrage empfangen und in einem Schritt T2 in einem Flag ein Wert zur Identifikation des CHECK-OUT-Vorganges bzw. CHECK-OUT-Vorganges gesetzt. In einem Schritt T3 wird entschieden, ob die CHECK-IN-Anfrage oder die CHECK-OUT-Anfrage des Benutzers erfaßt ist. Falls in Schritt T3 die CHECK-IN-Anfrage erfaßt worden ist, wird in einem Schritt T4 entschieden, ob das Flag den CHECK-OUT-Vorgang bezeichnet und, falls das Resultat in Schritt T4 NEIN ist, wird in einem Schritt T6 eine Fehlermeldung ausgegeben und die Anfrage wird nicht ausgeführt. Andererseits wird zu Schritt T3 zurückgekehrt, falls das Resultat im Schritt T4 JA ist. Falls im Schritt T3 die CHECK-OUT-Anfrage erfaßt worden ist, wird in einem Schritt T5 entschieden, ob das Flag den CHECK-OUT-Vorgang bezeichnet. Falls die Entscheidung in Schritt T5 NEIN ist, wird in einem Schritt T7 das Flag auf einen Wert gesetzt, das den CHECK- OUT-Vorgang bezeichnet. Ist in dem Schritt T5 das Ergebnis JA oder ist Schritt T7 abgeschlossen, so wird zu Schritt T3 zurückgekehrt.

Fig. 8 ist ein Diagramm zur Erläuterung der durch die Erfindung gewährleisteten Datenkonsistenz. Das in Fig. 8 gezeigte spezielle Beispiel entspricht dem in Fig. 3 gezeigten Beispiel, wo die Datenkonsistenz nicht gewährleistet war, so daß die vorteilhafte Wirkung der Erfindung leichter gewürdigt werden kann.

In Fig. 8 bezeichnet LT eine lange Übertragung des CHECK-IN/CHECK-OUT- Modells durch den Client A und ST bezeichnet eine lange Zugriffs-Übertragung durch den Client B. Die Anfangswerte der beiden Kontostände X und Y sind auf der Server- Seite in der öffentlichen Datenbank 29 gespeichert und betragen beide 100 Dollar. In diesem Fall transferiert die lange Übertragung LT 20 Dollar von dem Konto X zu dem Konto Y und die lange Übertragung ST berechnet die Summe der beiden Kontostände X und Y.

Zunächst wird durch die lange Übertragung LT der Kontostand X ausgecheckt, 20 Dollar von dem Kontostand X subtrahiert, der Kontostand Y ausgecheckt, 20 Dollar zu den Kontostand Y hinzuaddiert und der Kontostand X eingecheckt. Die lange Übertragung ST öffnet den Übertragungsvorgang und greift auf den Kontostand X zu (d. h. liest diesen). Somit sind bis zu diesem Punkt die Vorgänge identisch mit denen des in Fig. 3 gezeigten herkömmlichen Falles.

Wenn jedoch der Kontostand Y in Fig. 8 eingecheckt wird, wird anhand der Übertragungsliste 26c festgestellt, daß die andere Übertragung (ST), die die gleichen Daten (Kontostand X) wie die Übertragung (LT) verarbeitet, noch nicht beendet ist, und es wird das Einchecken des Kontostandes Y aufgeschoben. Anschließend wird das Einchecken des Kontostandes Y durch die lange Übertragung LT vollzogen, wenn die lange Übertragung ST den Kontostand Y ausgelesen, die Summe der Kontostände X und Y ausgedruckt und die Übertragung geschlossen hat. Demzufolge beträgt das Ergebnis von "X+Y" in der langen Übertragung LT "200 Dollar", was von dem Ergebnis des in Fig. 3 dargestellten gewöhnlichen Falles abweicht. Somit ist es, im Gegensatz zu dem in Fig. 3 dargestellten herkömmlichen Fall, im Fig. 8 gezeigten Fall der Erfindung möglich, Datenkonsistenz zu erreichen.

Fig. 8 zeigt also ein spezielles Beispiel, bei dem der CHECK-OUT-Vorgang vorübergehend aufgeschoben wird, bis die damit verbundene Übertragung abgeschlossen ist, so daß das CHECK-IN/CHECK-OUT-Modell und die Übertragungen ineinander integriert werden können, wobei Datenkonsistenz gewährleistet ist.

Claims (7)

1. Sperrmechanismus für ein CHECK-IN/CHECK-OUT-Modell, bei dem ein oder mehrere Clients (9) auf eine öffentliche Datenbank (8) eines Servers (1) zugreifen, gekennzeichnet durch
eine in dem Server (1) vorhandene Verwaltungsvorrichtung (2) für lange Übertragungen, zur Verwaltung von Übertragungen, die von dem Client (9) angefordert worden sind und einen CHECK-OUT-Vorgang, der Daten von der öffentlichen Datenbank (8) kopiert, und einen CHECK-OUT-Vorgang, der Daten zurück in die öffentliche Datenbank (8) schreibt, umfaßt,
eine in dem Server (1) vorhandene Verwaltungsvorrichtung (5) für kurze Übertragungen, zur Verwaltung von Übertragungen, die keine Daten von der öffentlichen Datenbank (8) kopieren, und
eine Übertragungsliste (7) zum Speichern von Informationen, die den Inhalt der durch die Verwaltungsvorrichtungen (2, 5) für lange bzw. kurze Übertragungen ausgeführten Übertragungen bezeichnen,
wobei die Verwaltungsvorrichtung (2) für lange Übertragungen eine Einrichtung beinhaltet, die dazu dient, das Einchecken von beliebigen Daten solange aufzuschieben, bis eine andere Übertragung, die auf die beliebigen Daten zugreift, beendet ist, wenn die andere Übertragung durch die Übertragungsliste (7) zwischen dem CHECK-OUT- Vorgang und dem CHECK-OUT-Vorgang erfaßt ist.

2. Sperrmechanismus nach Anspruch 1, dadurch gekennzeichnet, daß die Verwaltungsvorrichtung (2) für lange Übertragungen eine Einrichtung beinhaltet, die, wenn eine Übertragung, die auf die beliebigen Daten zugreift und zwischen dem CHECK-OUT-Vorgang und dem CHECK-OUT-Vorgang erzeugt worden ist, auf das Einchecken der beliebigen Daten wartet, die Ausführung anderer Übertragungen, die auf die beliebigen Daten zugreifen, so lange unterbindet, bis die Übertragung beendet ist.

3. Sperrmechanismus nach Anspruch 1 oder 2, dadurch gekennzeichnet,
daß die Übertragungsliste (7) mindestens eine Identifizierungsnummer jeder Übertragung, eine Identifizierungsnummer jeder Daten und eine Statusinformation bezüglich jeder Übertragung entsprechend einem Erneuerungsmodus und einem Zugriffsmodus jeder Übertragung beinhaltet und
daß die Verwaltungsvorrichtung (2) für lange Übertragungen und die Verwaltungsvorrichtung (5) für kurze Übertragungen abhängig von einer Übertragung, die ausgeführt wird, auf die Übertragungsliste (7) zugreifen, auf die Übertragung bezogene Informationen in einem Teil der Übertragungsliste entsprechend dem Modus abspeichern und die in Zusammenhang mit der Übertragung gespeicherten Informationen aus der Übertragungsliste (7) wieder löschen, wenn die Übertragung beendet ist.

4. Sperrmechanismus nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die Übertragungsliste (7) in dem Server (1) vorhanden ist.

5. Server mit einem Sperrmechanismus für ein CHECK-IN/CHECK-OUT-Modell, wobei ein Client (9) oder mehrere Clients auf eine mit dem Server (1) verbundene öffentliche Datenbank (8) zugreifen, gekennzeichnet durch
eine Verwaltungsvorrichtung (2) für lange Übertragungen, zur Verwaltung von durch den Client (9) angeforderten Übertragungen, die einen CHECK-OUT-Vorgang, der Daten von der öffentlichen Datenbank (8) kopiert, und einen CHECK-OUT-Vorgang, der Daten zurück in die öffentliche Datenbank (8) schreibt, beinhalten,
eine Verwaltungsvorrichtung (5) für kurze Übertragungen, zur Verwaltung von Übertragungen, die keine Daten von der öffentlichen Datenbank (8) kopieren, und eine Übertragungsliste (7) zum Speichern von Informationen, die den Inhalt der durch die Verwaltungsvorrichtungen (2, 5) für lange bzw. kurze Übertragungen ausgeführten Übertragungen bezeichnen,
wobei die Verwaltungsvorrichtung (2) für lange Übertragungen eine Einrichtung beinhaltet, die dazu dient, das Einchecken beliebiger Daten solange aufzuschieben, bis eine andere Übertragung, die auf die beliebigen Daten zugreift, beendet ist, wenn die andere Übertragung durch die Übertragungsliste (7) zwischen dem CHECK-OUT- Vorgang und dem CHECK-OUT-Vorgang erfaßt ist.

6. Server nach Anspruch 5, dadurch gekennzeichnet, daß die Verwaltungsvorrichtung (2) für lange Übertragungen eine Einrichtung beinhaltet, die dazu dient, die Ausführung anderer Übertragungen, die auf die beliebigen Daten zugreifen, solange zu unterbinden, bis eine Übertragung beendet ist, die auf die beliebigen Daten zugreift und zwischen dem CHECK-OUT-Vorgang und dem CHECK-OUT-Vorgang erzeugt worden ist und auf das Einchecken der beliebigen Daten wartet.

7. Server nach Anspruch 5 oder 6, dadurch gekennzeichnet,
daß die Übertragungsliste (7) mindestens eine Identifizierungsnummer jeder Übertragung, eine Identifizierungsnummer jeder Daten und eine mit jeder Übertragung verbundene Statusinformation entsprechend einem Erneuerungsmodus und einem Zugriffsmodus jeder Übertragung beinhaltet, und
daß die Verwaltungsvorrichtung (2) für lange Übertragungen und die Verwaltungsvorrichtung (5) für kurze Übertragungen abhängig von einer Übertragung, die ausgeführt wird, auf die Übertragungsliste (7) zugreifen, mit der Übertragung verbundene Informationen in einem Teil der Übertragungsliste (7) entsprechend dem Modus abspeichern, wenn die Übertragung ausgeführt wird, und die mit der Übertragung verbundenen Informationen aus der Übertragungsliste (7) wieder löschen, wenn die Übertragung beendet ist.