Objektidentität und Konflikterkennung

  In Kapitel 2.2.4 wurde die Abspeicherung der ConceptBase --Frames als Propositionen beschrieben. Ein wichtiger Teilaspekt dieser Tatsache ist, daß jede Proposition einen eindeutigen Identifikator hat. Zusätzlich lassen sich Propositionen nicht ändern sondern nur einfügen (TELL) oder entfernen (UNTELL). Hieraus wird klar, daß der Konflikttest wesentlich komplizierter ist, als in einer relationalen DB. Welche Konflikte können auf Propositionsebene überhaupt auftreten?

W/W:

Write--Write--Konflikte (also der Verlust von Änderungen) sind per Definition unmöglich, da Propositionen nur eingefügt werden können und jede neue Proposition auch eine neue ID erhält.

W/R:

Ein Lesen nicht freigegebener Änderungen würde zur Gefahr kaskadierender Abbrüche führen. Dies kann umgangen werden, indem man den in ConceptBase vorhandenen temporären Speicher zur Aufnahme aller Änderungen nutzt, die erst beim Commit global sichtbar gemacht werden.

R/W:

Ein solcher Konflikt kann nur auftreten, wenn eine gelesene Proposition von einer anderen Transaktion gelöscht werden soll. Falls hieraus eine referentielle Inkonsistenz entsteht, wird sie vom Integritätstester erkannt werden. Um Serialisierbarkeit zu erreichen, müßte diese Konfliktart verhindert werden.

Wie man sieht, sind auf Propositionsebene nicht sehr viele Konflikte zu erkennen, bzw. ihre Behebung ist meist einfach. Wenn man hingegen bei der Konflikterkennung von der 'Individual'--Ebene ausgeht, sieht es schon ganz anders aus:

W/W:

Durch die Länge der Transaktionen sind Schreibzugriffe verschiedener Transaktionen auf dasselbe Individual zu erwarten. Durch sie können wie bereits erwähnt keine Änderungen verloren gehen, aber das Einfügen widersprüchlicher Informationen kann -- für den Integritätstester nicht erkennbare -- Inkonsistenz erzeugen. Ein 'Employee', dem mehrere Benutzer gleichzeitig verschiedene Gehälter eintragen, ist ein solches Beispiel. Es läßt sich dadurch verhindern, das das Gehaltsattribute als ``single`` spezifiziert wird. Die Existenz von nicht so einfach behebbarer Beispiele ist unklar und wird in Kapitel 4.1.3 genauer behandelt.

W/R:

Dieser Konflikt läßt sich, wie oben bereits beschrieben, durch Benutzung des temporären Speichers vermeiden.

R/W:

Konflikte dieser Art müssen verhindert werden, wenn eine konsistente Analyse gewünscht wird:

Andererseits würde die Verhinderung von R/W--Konflikte während der Transaktionslaufzeit eine Benutzung von ConceptBase nahezu unmöglich machen, da viele Anwendungen als erstes den gesamten, sie interessierenden Datenbestand einlesen, um ihn dem Benutzer anzeigen zu können. Sobald aber zwei Transaktionen dies durchgeführt haben, kann keine von ihnen mehr ein Objekt ändern, ohne einen R/W--Konflikt auszulösen.

Es läßt sich also eine wesentlich größere Zahl möglicher Konflikte (insbesondere W/W) auf 'Individual'--Ebene erkennen. Dies ist jedoch mit höherem Aufwand verbunden und teilweise von fraglichem Nutzen. Ein zusätzliches Problem der Konflikterkennung auf Individualebene besteht darin, daß die Behandlung in den ProLog--Code eingesetzt werden müßte, während sich bei den Propositionen die sowieso entstehende Schnittstelle zwischen ProLog--Kern und Objektspeicher anbietet.