15.1 Verfahrensüberblick
15.1.1 Behandlung von Pufferinvalidierungen
Zur Erkennung/Vermeidung von Pufferinvalidierungen bestehen im wesentlichen die in Abb. 15-1 gezeigten Alternativen, welche in den folgenden Kapiteln noch näher vorgestellt werden. Erkennungsansätze sind dadurch charakterisiert, daß bei ihnen - im Gegensatz zu Vermeidungsstrategien - Pufferinvalidierungen möglich sind, diese jedoch entdeckt und aus dem Puffer entfernt werden. Bei der Broadcast-Invalidierung (Kap. 15.2) werden Änderungen über Broadcast-Nachrichten allen Rechnern mitgeteilt, so daß Pufferinvalidierungen frühzeitig erkannt werden. Dieser Ansatz ist für alle Synchronisationsmethoden anwendbar. Eine On-Request-Invalidierung (Kap. 15.3) ist dagegen nur für Sperrverfahren möglich. Dabei wird bei der Anforderung einer globalen Sperre - ohne Mehraufwand an Kommunikation - entschieden, ob eine gepufferte Objektkopie noch gültig ist oder nicht.
Abb. 15-1: Alternativen zur Erkennung/Vermeidung von Pufferinvalidierungen
Ein Buffer-Purge-Ansatz vermeidet Pufferinvalidierungen, indem DB-Seiten bereits am Transaktionsende aus dem Puffer entfernt werden, um ihre Invalidierung durch andere Transaktionen zu vermeiden. Ein solcher Ansatz kann jedoch zu einem sehr schlechten E/A-Verhalten führen, da im Puffer nur noch Lokalität innerhalb von Transaktionen zur Einsparung von Externspeicherzugriffen nutzbar ist. Ferner müssen sämtliche Änderungen am Transaktionsende in die physische Datenbank durchgeschrieben werden (Force-Strategie, s.u.). Der Buffer-Purge-Ansatz führt aufgrund dieser Beschränkungen meist zu einem inakzeptablen Leistungsverhalten und soll hier nicht weiter betrachtet werden[63]. Eine effektivere Methode zur Vermeidung von Pufferinvalidierungen ist der Einsatz von Haltesperren (Kap. 15.4). Dabei bleiben Seiten über das Transaktionsende hinaus gepuffert, jedoch werden sie durch spezielle Haltesperren (retention locks) vor ihrer Invalidierung geschützt. Dieser Ansatz ist nur in Verbindung mit pessimistischer Synchronisation möglich.
[63] Eine andere allgemeine Vermeidungsstrategie wäre, nur Seiten zu puffern, die nicht geändert werden. Da jedoch i.a. jede DB-Seite änderbar ist, kommt ein solcher "Ansatz" ebenfalls nicht in Betracht.