In früheren Kapiteln wurden drei Konfliktarten zwischen Schreib- und Leseoperationen genannt: R/W-, W/R- und W/W--Konflikte. Sie werden hauptsächlich bei der Bestimmung der Konflikt--Serialisierbarkeit von Transaktionen benötigt. Da aber dieses Konzept nicht mehr auf Serialisierbarkeit beruht, stellt sich die Frage, inwiefern die drei Konfliktarten noch aus anderen Gründen beachtet, erkannt und behoben werden müssen.
Für die R/W- und W/R--Konflikte läßt sich die Frage schnell negativ beantworten. Ein W/R--Konflikt entspricht einem 'dirty read', also dem Lesen noch nicht festgeschriebener Änderungen (vgl. Kap.\ 3.4.3, 3.1.2 und [GR93]). Dies kann im vorgestellten Konzept bei Transaktionen vom Isolationsgrad 2 nicht auftreten, da Änderungen grundsätzlich lokal gehalten werden und erst am Transaktionsende in die öffentliche Datenbasis eingefügt werden. Transaktionen in einer Isolationsgrad 0 gewährenden Gruppe sehen zwar sofort die Änderungen ihrer Mittransaktionen, dies entspricht aber dem Isolationsgrad und braucht darum nicht verhindert zu werden.
Der R/W--Konflikt bedeutet, daß ein Datenelement bei einem späteren
Lesezugriff einen anderen Wert aufweisen würde als bei einem früheren.
Genau diese Eigenschaft läßt 2
Isolation -- im Gegensatz zu
3
-- aber zu. R/W--Konflikte stellen also in diesem Konzept
keine Fehler, sondern eine erwünschte Verringerung der Isolation dar, so
daß sie ebenfalls nicht verhindert werden müssen.
Einen Problemfall stellt der W/W--Konflikt dar. Seine Hauptberechtigung zieht er neben der Konfliktserialisierbarkeit aus der Transaktionseigenschaft ``Dauerhaftigkeit``. Bei einem W/W--Konflikt überschreibt nämlich eine Transaktion Änderungen einer anderen, möglicherweise ohne sie vorher zur Kenntnis genommen zu haben. Die Änderungen würden also verloren gehen, was der ``Dauerhaftigkeit`` widerspricht. In ConceptBase wird ein solcher Informationsverlust aber bereits durch die Verwaltung der Propositionen unmöglich gemacht. Jede neu eingefügte Proposition erhält einen eindeutigen Identifikator und Änderungen an einmal eingetragenen Propositionen sind unmöglich. Außerdem kann eine Proposition nur gelöscht werden, wenn ihr Identifikator bekannt ist, was erst der Fall ist, wenn die sie erzeugende Transaktion erfolgreich abgeschlossen wurde. Ergebnisse einer Transaktion können also erst vernichtet werden, wenn sie nach Abschluß dieser Transaktion von einer anderen gelesen wurden. Das ist aber keine Verletzung der ``Dauerhaftigkeit``.
Neben Verletzungen der ``Dauerhaftigkeit`` kann ein W/W--Konflikt auch bedeuten, daß zwei Benutzer gleichzeitig ein Objekt verändern, ohne voneinander zu wissen. Hieraus resultierende Konsistenzverletzungen (z.B. Löschen des Objekts bei gleichzeitigem Einfügen neuer Attributwerte) werden vom Integritätstester erkannt. Möglicherweise gibt es aber Fälle, bei denen parallele Änderungen zu einem nicht inkonsistenten aber dem Verständnis von Korrektheit widersprechenden Ergebnis führen.
Das Beispiel ist natürlich an den Haaren herbeigezogen, zumal Änderungen der Instanziierungsbeziehung in diesem Ausmaß nie vorkommen sollten. Andere aufgetauchte Beispiele, die die Instanziierung konstant lassen, bewirken allerdings nur das Eintragen redundanter Informationen, was zwar nicht erstrebenswert aber auch nicht falsch ist.
Der Mangel an Beispielen für krasse Fehler durch W/W-Konflikte führte mich im Laufe meiner Überlegungen zu der Überzeugung, daß der für das Erkennen dieser Konflikte notwendige Aufwand in keinem Verhältnis zum dadurch erhaltenen Gewinn steht. Da ich aber andererseits keinen Ansatzpunkt gefunden habe, zu beweisen, daß nicht doch Beispiele mit schwereren Fehlern existieren, wird im folgenden der ursprünglich für die Erkennung von W/W--Konflikten vorgesehene Mechanismus beschrieben, wenn er auch nicht implementiert wurde.
Weil, wie in Kapitel 3.4.3 gezeigt, W/W--Konflikte auf
Propositionsebene nicht existieren, müssen sie auf Objektebene erkannt werden.
Als Konflikt wird angesehen, wenn zwei parallele
Transaktionen Änderungen am gleichen Objekt vornehmen; also, im Vorgriff auf
Begriffe aus der Implementierung, wenn verschiedene Transaktionen
gleichzeitig auslaufende Kanten in die Beziehungsmengen eines TOB (vgl.\
S.
und S.) einfügen oder aus
ihnen löschen. Zur Erkennung merkt sich jede Transaktion den Zeitpunkt ihres frühesten
Schreibzugriffs auf jedes Objekt und überprüft an ihrem Ende, ob zwischen
diesem Zeitpunkt und dem Transaktionsende
Änderungen an dem Objekt in die Hauptdatenbasis eingetragen
wurden. Ein positives Ergebnis dieses Tests bedeutet einen W/W--Konflikt.