Wie schon erwähnt, können die in Abschnitt 3.1 vorgestellten Konzepte nicht auf die Aufgabenstellung angewendet werden, da sie die Isolation zu gewährleisten suchen. Zudem wurde in 3.3.2 gezeigt, daß Sperrverfahren, die Lesezugriffe verweigern, sich mit deduktiven Datenbanken schlecht vertragen. Auch Escrow--Sperren sind von ihrer Konzeption mit Intervallen zu sehr von der Notwendigkeit der Unterstützung vielfältiger Datentypen entfernt.
Im Gegensatz zu den Escrow--Sperren, ließen sich 'Field Calls' auch in nicht--numerischen Datenbanken wie ConceptBase einsetzen. Allerdings ist die Angabe einer notwendigen Bedingung für die Ausführbarkeit der Änderungsoperation u.U. schwierig und ihre Auswertung bedeutet zusätzlichen Rechenaufwand: Zusätzlich nämlich zur ohnehin stattfindenden Auswertung der Integritätsbedingungen.
Das Konzept der Multigranularität ist auch für objektorientierte Datenbanken von Bedeutung. Die Instanziierungs- und Spezialisierungsbeziehungen formen hier einen gerichteten Graphen (siehe Bild 3.7), so daß Sperren auf verschiedenen Ebenen ebenfalls wünschenswert, wenn auch komplizierter, sind.
Beim DAG--Sperren, das ja für Graphen gedacht ist, ergeben sich Probleme aus den Tatsachen, daß ConceptBase s Objekthierarchie nicht zykelfrei ist und keine feste Struktur besitzt. Zudem läßt sich bei interaktiven Transaktionen nie vorhersagen, ob der Benutzer auf ein Datum später noch einmal zugreifen will. Dies wäre aber nach dieser Strategie unmöglich, wenn die Sperre auf dem Datum frühzeitig freigegeben wurde, da jedes Datum nur einmal gesperrt werden darf. Zur Anwendung in ConceptBase
müßte dieses Verfahren also in das Strikte 2PL--Protokol degeneriert werden, da Sperren erst beim Transaktionsende freigegeben werden dürften.
Bei den Zeitstempelverfahren stört insbesondere die Idee, die Transaktionen unbedingt in ihrer Startreihenfolge zu serialisieren, wodurch sich unnötige Transaktionsabbrüche ergeben können. Wie in Abschnitt 3.3.2 gezeigt, vereinfacht aber die Verwaltung von Versionen, um Lesevorgänge ungestört ablaufen lassen zu können, die Zusammenarbeit von Transaktionssystemen und deduktiven Datenbanken, so daß Multiversionen--Verfahren interessant sind.
Geschachtelte Transaktionen ermöglichen das Zusammensetzen einer Transaktion aus (einfacheren) Teiltransaktionen. ConceptBase kennt allerdings intern keine Transaktionsprogrammiersprache, in der solche Transaktion geschrieben und zusammengestellt werden könnten. Vielmehr bleibt die ``Programmierung`` des Transaktionsablaufes allein dem Applikationsprogrammierer überlassen, der dem ConceptBase --Server lediglich Anfragen und Änderungsoperationen übermitteln kann. Eine Änderung dieser Struktur ist (unter Kosten--Nutzen--Gesichtspunkten) weder zweckmäßig noch möglich. An ähnlichen Problemen scheitern die Mehrschichten-Transaktionen, die sich bekanntlicherweise die internen Abstraktionsstufen der Datenbank zunutze machen. In ConceptBase existieren lediglich zwei dieser Stufen: die Propositionsebene und die für den Benutzer sichtbare 'Frame'ebene. Die Befehle der 'Frame'ebene zeichnen sich nicht durch eine reichhaltige Semantik aus, durch deren Ausnutzung Mehrschichten--Transaktionen erst einen Parallelitätsgewinn versprechen würden. Auch der wesentliche andere Grund für einen Performancegewinn mit Mehrschichten--Serialisierbarkeit, die Vergröberung der Sperrgranularität auf der untersten Ebene durch die Verwaltung von Sekundärspeicherseiten, existiert in ConceptBase (bisher) nicht.
Da die klassischen Konzepte also nur Denkansätze bieten, ist es natürlich interessant zu sehen, ob die fortgeschrittenen Systeme geeignetere Lösungsansätze bieten. Leider sieht man ihnen ihre Herkunft aus dem objektorientierten Bereich meist an. So ist die Ausnutzung der Kommutativität von Objektmethoden zwar eine gute Idee, sie stößt aber an ihre Grenzen, wenn die einzigen ``Methoden``, die es gibt, TELL, UNTELL und ASK sind, also schließlich doch nur Schreib-/Leseoperationen.
Die Verwendung von Kompensationsfunktionen/-transaktionen würde es erlauben,
Sperren nur kurzfristig zu halten, und damit viele der in Kapitel 3.3.2
genannten Schwierigkeiten beim Zusammentreffen von Sperren und deduktiven
Datenbanken lösen. Eine Definition von Kompensationsfunktionen für die von
ConceptBase
zur Verfügung gestellten Operationen (s.o.) scheitert aber an
deren geringem semantischen Gehalt. Da ConceptBase
zudem keine
Programmiersprache besitzt, in der Transaktionen und ihre
Kompensationsfunktionen in die Datenbank integriert werden könnten, müßte
die Durchführung einer etwaigen Kompensation allein von dem
Applikationsprogramm sichergestellt werden. Dies ist nicht nur
fehlerträchtig -- auch Applikationsprogrammierer sind vergeßlich --,
sondern bürdet dem Entwerfer der Anwendung die Schwierigkeit auf,
Kompensationstransaktionen zu entwerfen, die auch im Zusammenspiel mit ihm
unbekannten anderen Anwendungen noch funktionieren sollen. Dies zumal Operationen
in ConceptBase
nur selten kommutativ sind.
Es lassen sich auch einfach Beispiele konstruieren, in denen eine Kompensation als unmöglich angesehen werden muß. Betrachtet man z.B. die Bemerkungen ('annotation') in der Anwendung ``CoAuthor``, so kann es Probleme geben, wenn eine einmal eingefügte Bemerkung wieder entfernt werden soll. Erstens können an diese Bemerkung andere Bemerkungen angehängt worden sein, was sich allerdings noch sinnvoll durch ein Mitlöschen dieser Bemerkungen lösen ließe. Zweitens kann eine negative Anmerkung eine Abstimmung über das zugehörige Objekt auslösen, die u.U. negativ ausgeht, worauf das Objekt entfernt wird. Soll und kann das Objekt wieder zurückgeholt werden, wenn die die Abstimmung auslösende Bemerkung wieder entfernt wird?
Einen für die angestrebte Verwendung zu niedrigen Parallelitätsgrad ermöglicht die Restrukturierung von Transaktionen, da weiterhin durch lange Sperren Lesezugriffe verhindert würden. Auch setzt die Spezifiktation der 'Read-' und 'Writesets' durch den Benutzer bei ihm ein Wissen über das zugrundeliegende Schema der Datenbank und den bisherigen Ablauf der Transaktion voraus, wenn die Bedingungen (3.1) bis (3.5) eingehalten werden sollen. Interessant erscheint allerdings die Idee, konsistente Teilergebnisse einer Transaktion freigeben zu können, ohne die ganze Transaktion beenden zu müssen.
Benutzerdefinierte Korrektheits- und Synchronisationskriterien stellen einerseits eine passende Erweiterung zu ConceptBase dar. Während ConceptBase durch seine Integritätsbedingungen die Datensemantik nutzt, beruht dieses Konzept auf Verwertung der den Transaktionen inhärenter Semantik. Auch das Abspeichern des zur Auswertung benötigten Wissens in Regeln/Grammatiken in der Datenbank ist beiden Konzepten gemein. Allerdings träten die bereits in der Beschreibung in Kapitel 3.2.2 angeführten Schwierigkeiten beim Entwurf der zur Beschreibung der erlaubten Verhaltensweisen benötigten Regeln in ConceptBase verstärkt auf. In eingen Modellierungsanwendungen werden Arbeitsablaufschemata dynamisch entwickelt, so daß eine Grammatik am Ende der Entwicklung stehen könnte, aber nicht als Voraussetzung.
Das DDG-Verfahren ist das einzige Verfahren, das gezielt für deduktive Datenbanken entwickelt wurde. Es versucht insbesondere das Problem, daß durch die Auswertungsmechanismen große Teile der Datenbank gesperrt werden müssen (vgl. Kap. 3.3.2), zu umschiffen, indem es ein nicht--zweiphasiges Verfahren verwendet. Der Freigabe von Sperren, die nicht mehr benötigt werden, steht nun nichts mehr entgegen. Obwohl aber ConceptBase
eine deduktive Datenbank ist, sieht es mit der Anwendbarkeit schlecht aus.
Die langen, interaktiven Transaktionen, die keine Voraussage der Lese- und
Schreibmengen ermöglichen, führen bei diesem Verfahren dazu, daß eine
Transaktion tatsächlich die ganze Datenbasis sperren müßte (Sperre auf den
Wurzelknoten), um dem Benutzer alle Möglichkeiten offen zu halten.
Für das Setzen kurzfristiger Sperren (z.B. während der Auswertung einer
einzigen Anfrage oder in Verbindung mit dem 'Sagas'--Konzept) böte sich
dieses Verfahren allerdings an.
Da das Gruppenkonzept im Gegensatz zu den Geschachtelten Transaktionen Daten und nicht Transaktionen aufteilt, erscheint es für ConceptBase
anwendbar. Insbesondere bei Benutzung eines ConceptBase --Servers durch verschiedenste Anwendergruppen ist eine Unterteilung in Gruppen mit unterschiedlicher Isolation nach innen und außen wünschenswert. Mittels einer Einteilung in Gruppen ließe sich auch eine Beschränkung der Änderungen der Benutzer auf ihnen zugeordnete Daten realisieren. Nicht vernachlässigt werden darf natürlich der durch die Verwaltung von Gruppen steigende Zugriffsaufwand auf Daten.
Eine Einschränkung der Brauchbarkeit des Tool Kit Ansatzes ergibt sich dadurch, daß er bisher hauptsächlich für eine Verwendung von Sperren ausgearbeitet wurde. Und während die Idee, jedem Applikationsentwickler die Entscheidung über das für ihn am sinnvollste Transaktionskonzept selbst zu überlassen, durchaus interessant erscheint, dürfte die Implementierung der hierfür notwendigen Grundbausteine und Kontrolleinheiten ziemlich arbeitsaufwendig sein.
Table: Übersicht über die vorgestellten
Transaktionskonzepte
Wenn auch NSE von SUN inzwischen wegen Problemen mit der Betriebssystemeinbindung eingestellt wurde, so bietet es doch interessante Ansätze. Insbesondere den Benutzer bei der Beseitigung von Kon flikten zu unterstützen (wie es ja auch [BK91, S.281,] fordern), statt einfach die Transaktion abzubrechen, und ihm lediglich Änderungen in abgegrenzten Bereichen zu erlauben, könnte in ein Transaktionskonzept für ConceptBase integriert werden. Andererseits erscheint die Isolation zwischen den einzelnen Entwicklern auf unterster Stufe zwar für Programmieraufgaben angemessen, dürfte für interaktivere Anwendungen aber zu hoch sein.
Es bleibt also festzuhalten, daß sich nicht nur die klassischen Transaktionskonzepte, sondern auch viele fortgeschrittene Verfahren für ConceptBase
schlecht eignen, da ConceptBase
einige Abweichungen vom Standarderscheinungsbild neuerer Datenbanksysteme (insbesondere objektorientierter) zeigt. Zum einen bieten TELL, UNTELL und ASK nicht die reichhaltige Operationssemantik, die viele Konzepte auszunutzen versuchen. Aber auch die Tatsache, daß ConceptBase keinerlei Transaktionsprogrammierung gestattet, verringert für einige Konzepte (z.B. Kompensationsfunktionen) die Anwendbarkeit. Die Interaktivität der ConceptBase --Anwendungen läßt zudem wenig Vorhersagen über den Transaktionsverlauf zu, was z.B. dem DDG--Konzept, aber auch einigen nicht vorgestellten Verfahren, die die Read- und Writesets der Transaktionen benötigen, zu schaffen macht.
