15 Kohärenzkontrolle

15.3 On-Request-Invalidierung

Der hohe Kommunikationsaufwand einer Broadcast-Invalidierung kann für Sperrverfahren umgangen werden, wenn die globale Sperrtabelle auch um Informationen zur Erkennung von Pufferinvalidierungen erweitert wird. Dies erlaubt es dem GLM bei der Bearbeitung einer Sperranforderung ("on request"), die vor jedem Objektzugriff erforderlich ist, darüber zu entscheiden, ob eine in dem Rechner gepufferte Kopie der Seite noch aktuell ist [Ra86b]. Damit können veraltete Seiten völlig ohne zusätzliche Kommunikationsvorgänge und Antwortzeitverschlechterungen erkannt werden, wodurch eine weit effizientere Kohärenzkontrolle als mit der Broadcast-Invalidierung erreicht wird. Die Information zur Erkennung von Pufferinvalidierungen ist bei Änderung einer Seite anzupassen. Auch dies kann ohne Zusatzkommunikation zusammen mit der Freigabe der Schreibsperre vorgenommen werden. Von Nachteil gegenüber der Broadcast-Invalidierung ist, daß invalidierte Seiten erst bei erneutem Zugriffswunsch entdeckt und somit später aus dem Puffer entfernt werden. Dies kann zu schlechteren Trefferraten führen, da der Puffer durch nicht nutzbare Seiten belegt wird.

Wir diskutieren im folgenden zwei Realisierungsansätze zur On-Request-Invalidierung, nämlich die Nutzung von Versionsnummern sowie von Invalidierungsvektoren. Zur Einfachheit unterstellen wir dabei zunächst eine Force-Strategie, bei der die aktuelle Seite von der physischen Datenbank gelesen werden kann. Anschließend betrachten wir dann die Integration der Update-Propagierung für Noforce, und zwar sowohl bei dynamischer als auch fester Page-Owner-Zuordnung.

15.3.1 - Versionsnummern und Invalidierungsvektoren
15.3.2 - Dynamische Page-Owner-Zuordnung
15.3.3 - Feste Page-Owner-Zuordnung