15.2 Broadcast-Invalidierung
15.2.1 Zusammenwirken mit der Synchronisation
Abb. 15-4 zeigt die durch die Broadcast-Invalidierung erforderlichen Erweiterungen der Commit-Behandlung beim Einsatz von Sperrverfahren. Das Verschicken der Broadcast-Nachricht erfolgt dabei nach der ersten Commit-Phase, wenn die Wiederholbarkeit und damit der Erfolg der Änderungstransaktion sichergestellt ist. Erst nachdem alle Rechner das Eintreffen und die Bearbeitung der Broadcast-Nachricht quittiert haben, kann die Sperrfreigabe erfolgen. Denn eine frühere Sperrfreigabe würde es ermöglichen, daß die Sperre an einem anderen Rechner erworben und eine veraltete Seitenkopie im Puffer referenziert wird. Da Änderungstransaktionen synchron auf das Eintreffen der Quittierungen warten müssen, bezeichnen wir diesen Ansatz als synchrone Broadcast-Lösung. Der offensichtliche Nachteil neben dem hohen Kommunikations-Overhead ist die starke Erhöhung der Antwortzeiten und Sperrhaltezeiten. Dennoch verfolgten die ersten Shared-Disk-Implementierungen (IMS Data Sharing [SUW82], Computer Console [WIH83] etc.) einen solch einfachen Ansatz, und zwar in Verbindung mit einer Force-Ausschreibstrategie, welche die Commit-Bearbeitung zusätzlich stark verlängert.
Für optimistische Synchronisationsverfahren wird der Zugriff auf veraltete Seiten erst während der Validierung erkannt und führt zur Rücksetzung der betroffenen Transaktion. Die Broadcast-Benachrichtigungen sind wesentlich zur Begrenzung der Rücksetzhäufigkeit, da sie eine frühzeitige Eliminierung von Pufferinvalidierungen gestatten. Allerdings kann damit der Zugriff auf veraltete Daten nicht ausgeschlossen werden, da der Objektzugriff unsynchronisiert erfolgt und die erfolgreiche Beendigung einer Änderungstransaktion alle zuvor bereits referenzierten Objektversionen nachträglich invalidiert. Daher genügt bei optimistischer Synchronisation auch eine asynchrone Broadcast-Invalidierung, bei der die Broadcast-Nachricht erst nach Ende der Änderungstransaktion verschickt wird, ohne also ihre Antwortzeit zu verlängern. Die Broadcast-Nachrichten können auch dazu genutzt werden, Transaktionen aller Rechner abzubrechen, die bereits auf nunmehr invalidierte Objektversionen zugegriffen haben [Ra87]. Durch den frühzeitigen Abbruch dieser zum Scheitern verurteilten Transaktionen kann unnötige Arbeit zu ihrer Beendigung eingespart werden.
Abb. 15-4: Synchrone Broadcast-Invalidierung
