Im folgenden wird die Architektur des Objektservers und des den Kernen zugeordneten Transaktionsmanagerteils anhand zweier Grafiken dargestellt und die Funktionsweise erläutert. Es dürfte klar sein, daß eine ausführliche Dokumentation den Rahmen dieser Ausarbeitung sprengen würde. Interessenten seien auf den entsprechenden Sourcecode verwiesen.
Figure 4.6: Architektur des dem ProLog-Kern zugeordneten Transaktionsmanagers
Der Abbildung 4.6 dargestellte Teil des Transaktionsmanagers befindet
sich unter der Propositionsschnittstelle von ConceptBase
(in Abbildung
2.3 also im Bereich A). Er kontrolliert dort den Zugriff auf die
Propositionen und leitet Befehle des Benutzers an den Objektserver weiter.
Dem direkten Kontakt mit den ProLog--Routinen dienen die drei
funktionalen Module Antwort, Prop und Commands. Das Erste
realisiert die Auswertung von retrieve_prop--Anfragen mit verschiedenen
Suchmustern, indem es die Ergebnis--OID--Mengen zurückgibt.
Das zweite Modul
enthält Funktionen, um Propositionen zu schreiben und zu löschen, während
das dritte Funktionen für die Ausführung aller sonstigen Befehle (also z.B.
Erzeugen einer Transaktion/Gruppe, Beenden einer Transaktion, Hochspielen von
Änderungen in Gruppen, ...) enthält. Die Module erlangen anhand eines
mitübergebenen Transaktionsidentifikators aus einer
Hashtabelle den Zeiger auf das zugehörige Transaktionsobjekt ( TA) und nutzen
hauptsächlich die von diesem zur Verfügung gestellten Methoden.
Alle Speicherzugriffe von Instanzen der TA--Klasse laufen über den der jeweiligen Transaktion zugeordneten temporären Speicher TempMem. Angefragt werden kann ein TOB, das durch seine OID spezifiziert wird, oder die Menge aller OIDs von Propositionen mit einem bestimmten Label. Der temporäre Speicher prüft, ob er die gesuchte Information selbst hält, bzw. ob sie ihm als gelöscht bekannt ist. Andernfalls wird die Anfrage an den Cache weitergeleitet.
Der Cache ist im Gegensatz zu den temporären Speichern nur einmal pro Kern vorhanden. Dies erhöht zwar die Komplexität der Verwaltung, spart aber andererseits Speicher, da für eine Gruppe ge'cache'te Daten auch von anderen Gruppen genutzt werden können. Der Zugriff auf die Propositionen erfolgt über die CacheGroupData--Struktur, die für jede benötigte Gruppe existiert. Mit der in ihr enthaltenen Hashtabelle kann auf die im Cache enthaltenen Propositionen zugegriffen werden. Läßt sich eine gesuchte Proposition oder ein gesuchtes Label hier nicht finden und ist auch nicht als ``im Objektserver nicht vorhanden`` bekannt, so wird eine Anfrage an den Objektserver gestellt. Die geschieht mittels eines K_Message--Objekts, das zusammen mit einigen anderen die Benutzung der TLI--Funktionen (TLI=Transport Level Interface; vgl. [Sun93b]) kapselt.
Der Kern kann vom Objektserver zwei Arten von Nachrichten erhalten. Zum einen
Antworten auf Anfragen des Caches, die dieser in seinen Speicher einordnet.
Zum anderen Mitteilungen des Servers über Änderungen in einer der Gruppen,
auf die vom Kern bisher zugegriffen wurde. Diese Änderungsmeldungen, die das
Sichtbarwerden der von anderen Kernen durchgeführten Änderungen gemäß
2
Isolation bewirken, werden vom Modul Commands verarbeitet
und in Änderungen im Cache und Mitteilungen an die betroffenen Transaktionen
umgesetzt.
Figure 4.7: Architektur des Objektservers
In Abbildung 4.7 wird der Aufbau des Objektservers aus C0.42mm ++ --Objekten dargestellt. Im Gegensatz zum Kern laufen hier mehrere 'Thread's parallel ab. Der Hauptprozeßfluß befindet sich in der Mainloop des Server--Objekts. Bei Meldungen neuer Kerne am incoming--Port erzeugt er einen neues Client--Objekt mit zugehörigem 'Thread', das in Zukunft für alle Anfragen und Befehle des Kerns zuständig ist. Eingehende Nachrichten auf den im Portarray abgelegten Deskriptoren veranlassen den Server--'Thread' den zum Deskriptor gehörenden Client aufzuwecken, damit er auf die Nachricht reagieren kann.
Der in jedem Client--Objekt ablaufende 'Thread' kann über die im Server vorhandenen
Tabellen auf die zur Bearbeitung eines Befehls benötigte Gruppe Group zugreifen.
Die der Gruppe bekannten Propositionen verwaltet GroupMem, das Leseanfragen unverändert
an Mem weitergibt und das von dort gelieferte Ergebnis mit den in der Gruppe bekannten
Propositionen ( currently_known_OIDs) schneidet (vgl. S.4.2.2).
Fügt ein Client neue Propositionen in eine Group ein, so muß er dies allen
anderen Client--Objekten mitteilen, die einen Kern versorgen, der eine Transaktion in
dieser Gruppe besitzt. Jedes Client--Objekt schickt daraufhin eine Nachricht mit den
eingetretenen Änderungen an seinen zugeordneten Kern, damit dort
der Cache angepaßt werden kann.
DBconv erlaubt es, den von einem unmodifizierten ConceptBase
--Server abgespeicherten
Propositionenbestand in den Hauptspeicher Mem aufzunehmen.
Im folgenden wird noch genauer auf einige Facetten der Implementation eingegangen, die nicht den Gewohnheiten entsprechen.