Locks zur Sicherstellung referentieller Integrität

Jonathan Lewis wiederholt in seinem Blog zur Zeit allerlei Erläuterungen, die er schon häufiger gegeben hat, und ich wiederhole hier dann noch mal die Punkte, die es bisher trotz Wiederholung noch nicht bis in meinen aktiven Wissensbestand geschafft hatten (sondern nur eine vage Erinnerung aufrufen). Einer dieser Punkte betrifft das Verhalten der Locks zur Gewährleistung referentieller Integrität, die als RI Locks bezeichnet werden. Dabei skizziert der Autor folgendes Szenario:

• ein Datensatz wird in eine Parent-Tabelle eingefügt, aber nicht über commit festgeschrieben.
• in einer zweiten Session soll in eine child-Tabelle ein Datensatz eingefügt werden, der sich auf den neuen Parent-Datensatz bezieht.
• man könnte annehmen, dass die zweite Session unmittelbar einen Fehler erhält, der darauf hinweist, dass kein parent key gefunden wurde, aber das ist nicht der Fall: tatsächlich wartet die zweite Session darauf, dass in der ersten Session ein Commit oder ein Rollback erfolgt.
• obwohl das isolation level READ COMMITTED dafür sorgt, dass eine Session nur die Daten sehen kann, die in einer anderen Session bereits per commit festgeschrieben wurden, kann der zugehörige interne Prozess durchaus die Arbeit anderer Sessions wahrnehmen. 
• ein Blick in v$lock zeigt, dass die zweite Session ein TX Lock im Mode 6 hält (also ein exklusives Transaktionslock, was bedeutet, dass die Session undo und redo erzeugt); außerdem wird ein weiteres Transaktionslock in Modus 4 (share) angefordert, und diese Anforderung wird von der ersten Session blockiert.
• nach einem rollback in Session 1 wird in Session 2 dann der erwartete Hinweis auf den fehlenden parent key geliefert (ORA-02291). Nach einem commit in Session 1 kann Session 2 problemlos weiterarbeiten.
• im Fall einer multi-statement-Transaktion in Session 2 würde nur das insert in die child-Tabelle zurückgerollt werden, nicht aber alle Statements der Transaktion.
• das Verhalten ist das gleiche im Fall von update und delete.
• aus dem Verhalten können sich auch deadlocks ergeben.
• wenn in einem deadlock-Graphen ein TX wait des Typs S (share, mode 4) erscheint, sind mit hoher Wahrscheinlichkeit Indizes im Spiel (verursacht durch referentielle Integritätsregeln oder auch PK-Werte-Kollisionen oder Werte-Kollisionen in einer IOT).

Ob ich mir das jetzt besser merken kann, bleibt abzuwarten.