15.2 Broadcast-Invalidierung
Die wesentliche Aufgabe bei diesem Ansatz besteht in der Lokalisierung des Page-Owners. Hierbei bestehen ähnliche Möglichkeiten wie zur GLM-Lokalisierung bei dynamischen GLA-Zuordnung (Kap. 14.4). Allerdings kann jetzt die Lokalisierung ohne zusätzliche Nachrichten erreicht werden! Hierzu betrachten wir im folgenden zwei Möglichkeiten, wobei die erste auf die Broadcast-Invalidierung ausgerichtet und sowohl bei Sperrverfahren als auch optimistischer Synchronisation anwendbar ist. Der zweite Ansatz zur Page-Owner-Lokalisierung ist nur für Sperrverfahren möglich, jedoch auch bei einer On-Request-Invalidierung sowie beim Haltesperren-Ansatz einsetzbar.
Im Falle der Broadcast-Invalidierung kann jeder Rechner in einer replizierten Page-Owner-Tabelle vermerken, welcher Rechner für eine geänderte Seite zuständig ist. Diese Tabelle kann ohne zusätzliche Kommunikation geführt werden, indem in den Broadcast-Nachricht mitgeteilt wird, wo die Seitenänderung stattfand und daher die Page-Owner-Funktion vorliegt. Die Page-Owner-Tabelle wird immer konsultiert, sobald eine zu referenzierende Seite nicht im Hauptspeicher gepuffert ist. Besteht für die Seite ein Page-Owner-Eintrag, wird eine Seite bei dem vermerkten Rechner angefordert; ansonsten wird die Seite von der physischen Datenbank eingelesen. Ausschreibvorgänge durch den Page-Owner können mit anderen Broadcast-Nachrichten des Rechners asynchron an alle Rechner mitgeteilt werden. Daraufhin werden die entsprechenden Einträge der Page-Owner-Tabellen gelöscht, da die Seiten nun vom Externspeicher gelesen werden können. Diese Vorgehensweise begrenzt den Umfang der Page-Owner-Tabellen und ist notwendig zur weitgehenden Vermeidung von Seitenanforderungen, die vom Page-Owner nicht mehr befriedigt werden können.
Für Sperrverfahren, die einen Globalen Lock-Manager-Ansatz verfolgen, ist eine noch effizientere Lösung zur Page-Owner-Lokalisierung möglich. Denn in diesem Fall kann für geänderte Seiten der Page-Owner in der globalen Sperrtabelle vermerkt werden, so daß die replizierte Speicherung der Page-Owner-Angaben entfällt. Die Nutzung der Page-Owner-Information ist auch ohne zusätzlichen Kommunikationsvorgänge möglich. Denn der GLM kann bei der Antwort auf eine Sperranforderung mitteilen, welcher Rechner als Page-Owner fungiert. Die Eintragung eines Page-Owners ist zusammen mit der Bearbeitung einer Schreibsperre möglich, die für eine Änderung benötigt wird. Nach Ausschreiben einer geänderten Seite durch den Page-Owner kann dies wiederum asynchron an den GLM-Rechner mitgeteilt werden, woraufhin der Eintrag zurückgesetzt wird. Beispiele zum Einsatz dieser Page-Owner-Lokalisierung werden später vorgestellt (Beispiel 15-3, Beispiel 15-6).
Die Erweiterung der globalen Sperrtabelle für Aufgaben der Kohärenzkontrolle ist ein sehr effektiver Optimierungsansatz, die weitergehend nutzbar ist. Dies wird bei den noch vorzustellenden Alternativen der On-Request-Invalidierung sowie den Haltesperren getan. Jedoch auch für die synchrone Broadcast-Invalidierung läßt sich der Kommunikationsaufwand reduzieren, wenn in der globalen Sperrtabelle genau vermerkt wird, welche Seiten wo gepuffert sind. Bei der Gewährung einer Schreibsperre kann der GLM dann mitteilen, wo die betreffende Seite gepuffert ist, so daß am Transaktionsende nur noch diese Rechner benachrichtigt werden[65]. Dieser Ansatz entspricht somit einer Multicast-Invalidierung; in [DY93] wurde er als selektive Notifikation bezeichnet. Die Wartung der Pufferbelegung in der globalen Sperrtabelle kann weitgehend ohne zusätzliche Nachrichten geschehen, indem das Einlagern einer Seite mit der Sperranforderung signalisiert wird. Ausschreibvorgänge können wiederum asynchron und kombiniert mit anderen Sperrnachrichten mitgeteilt werden. Dennoch bleibt ein enormer Wartungsaufwand, da jede Änderung in der Pufferbelegung eines Rechners in der globalen Sperrtabelle nachgeführt werden muß. Dieser Aufwand steigt mit der Puffergröße sowie der Rechneranzahl.