Im Rahmen der Implementierung des Transaktionskonzeptes ergaben sich einige Probleme aus der Struktur des ConceptBase --Servers, die insbesondere den Sinn eines Integrationversuches zweifelhaft werden ließen.
Bei der Besprechung der Architektur von ConceptBase
(s. S.
f) wurde zwar dargestellt,
daß aus den Regeln und 'Constraints' abgeleitete Information außerhalb der
Propositionendatenbasis abgelegt werden. Der Aufbau unterhalb des Moduls
AssertionCompiler wurde allerdings wegen seiner Komplexität ignoriert. Die
dort stattfindenden Operationen stören einen Transaktionsmanager jedoch
erheblich.
Durch die Module LTAssertionCompiler, LTAssertionTranslator und
LTcodeGenerator werden nämlich die in Objekten enthaltenen Regeln,
soweit sie keine 'MagicSet'--Regeln sind, in ausführbaren
ProLog--Code umgewandelt und durch das Module PROLOGruleProcessor
schließlich mittels assert() in das ConceptBase
implementierende
ProLog-Programm eingefügt.
Diese dynamischen Änderungen am Programmcode beenden nicht nur jede Reentranz (vgl. Kap.4.2.1). Der so außerhalb der Propositionendatenbasis und damit außerhalb der Reichweite des Transaktionsmanagers abgespeicherte Code wird auch beständig zur Auswertung von Anfragen und Regeln benutzt. Aber auch bei einer Ausdehnung des Transaktionsmanagers ließe sich der Zugriff nicht beschränken, da der in das ProLog--Programm eingefügte Code direkt durch den ProLog--Interpreter ausgewertet wird. Ein unbeschränkter Zugriff führt aber dazu, daß für die Transaktionen aller Regelcode sichtbar ist, auch der Code solcher Regeln, deren Propositionsdarstellung für sie unsichtbar ist. Die Transaktionen werten also Anfragen mit Hilfe von Regeln aus, die sie gar nicht kennen dürften.
Dieses Problem stellt sich unabhängig vom verwendeten Transaktionskonzept sobald eine Transaktion A mehr Regeln ``sieht`` als eine andere. Um die korrekte Ausführung von A sicherzustellen, muß nämlich der Code für die entsprechenden Regeln eingefügt werden und ist damit für alle sichtbar. Unterschiede in der Sichtbarkeit treten aber beim Einfügen neuer Daten in allen Konzepten auf.
Zur Lösung sind drei Ansätze möglich:
Diese Vorgehensweise hat allerdings einige Nachteile. Zum einen verbraucht das Erzeugen und Löschen eines kompletten Kerns am Anfang und Ende jeder Transaktion ein großes Maß Rechenzeit und Speicher. Zum anderen löst es einige der weiter unten stehenden Probleme (wie z.B. das Abspeichern des Regelcodes in einer eigenen Datei) nicht, sondern verschärft sie noch.
Komplizierter wird dieses Verfahren allerdings, sobald der Code mehr als einer -- aber nicht allen -- Transaktionen zur Verfügung stehen soll. Um das mehrfache Einfügen des Codes zu vermeiden, müßten entweder statt `` Transaktion(142)`` kompliziertere Ausdrücke eingfügt werden oder es müßte auf noch einzuführende ``Transaktionsgruppen`` getestet werden. Alle Transaktionen innerhalb einer Transaktionsgruppe zeichneten sich dann dadruch aus, daß für sie die selben Regeln sichtbar sind. Da bereits das Einfügen einer neuen Regel in eine Klasse die Regelsicht einer Transaktion verändert, stimmten Transaktionsgruppen nicht mit den Gruppen des Transaktionskonzeptes überein.
Wie man sieht, kann die Komplexität der durchzuführenden Umwandlung erheblich sein. Außerdem verlangsamen die zusätzlich eingefügten Audrücke die Regelauswertung. Da zudem auch dieser Ansatz einige der folgenden Probleme ungelöst läßt und Änderungen in den obskureren Regionen von ConceptBase erfordert, erscheint auch dieser Ansatz als zumindest sehr aufwendig zu implementieren.
Die Auslagerung des Codes verhindert aber die Fortführung der bisherigen Strategie, die Auswertung aus Geschwindigkeitsgründen dem ProLog--Interpreter zu überlassen. Da der Code nicht mehr in das ProLog--Programm eingefügt werden darf, ist er für den Interpreter nicht mehr sichtbar. Die Regelauswertung müßte also von einem Meta--Auswerter übernommen werden, was die Leistung deutlich verringern würde.
Ein weiteres Problem stellen die von ConceptBase zur Beschleunigung von Konsistenztest und Regelauswertung benutzten Trigger dar. Die Trigger lösen bei einer Änderung der Daten die anhängenden Regeln und Konsistenzchecks aus. ConceptBase
bemerkt allerdings Änderungen nur, wenn sie verschiedenen ProLog--Module durchlaufen, wenn sie sozusagen die Kernarchitektur ,,von oben`` erreichen. Beim vorgestellten Konzept werden Änderungen in den Gruppen allerdings zwischen den einzelnen auf Propositionsebene arbeitenden Transaktionsmanager ausgetauscht, kommen also ,,von unten``. Um die Triggerauslösung zu gewährleisten müßte also der an den Kern gekoppelte Teil des Transaktionsmanagers diesem ankommende Änderungen mitteilen. Aufgrund dieser Mitteilungen könnten noch zu schreibende Routinen im Kern überprüfen, welche Trigger beeinflußt wurden.
Die Regelübersetzungen ließen sich theoretisch bei jeden Hochfahren des Servers aus den in der Propositionendatenbasis vorhandenen Informationen neu erzeugen. Um den hierfür notwendigen Aufwand zu sparen, speichert die derzeitige ConceptBase --Implementation den Regelcode ab. Allerdings geschieht dies völlig getrennt von den Propositionen in einer ``.rule``--Datei. Schwierigkeiten ergeben dadurch, daß es im vorgestellten Konzept mehrere Kerne gibt, die jeweils eine ``.rule``--Datei lesen und schreiben. Selbst wenn das gegenseitige Überschreiben verhindert werden kann, ist dieses Vorgehen weder speicheffizient, noch existiert eine primäre, bei Widersprüchen ausschlaggebende Version der Datei. Die einfachste Abhilfe für dieses Problem stellt die oben erwähnte Abspeicherung des ProLog--Codes in der Propositionenbasis dar.
Selbst bei Lösung aller dieser Probleme wäre die Integration noch durch einen bei den Integrationsversuchen des Objektspeichers von Hubertus Pützer sichtbar gewordenen Fehlers in BIM--Prolog behindert worden. Mit Abhilfe wird erst in der nächsten Version gerechnet.
Zusätzliche Schwierigkeiten bereitet die Einbeziehung der bisher in ConceptBase
vorhandenen historischen Datenbank, da der Objektspeicher von Hubertus Pützer hierfür bisher keine Unterstützung bietet. Zwar ließe sich die von Thomas List gewählte Implementierung der historischen Datenbank durch OID--Mengen übernehmen. Aber auch sie enthält keine Maßnahmen zur Auslagerung historischer Information auf langsamere Speichermedien.