Transaktionsorientierte Systeme erfordern insbesondere in einem verteilten DV-System enorme Rechnerkapazitäten und dementsprechend hohe Performance-Werte. Um die Transaktionen zu beschleunigen, wird vielerorts versucht, sie aus der Anwendungsebene auf die des Betriebssystems oder des Mikrocode zu verlagern. Edgar Nett*) beschreibt die Voraussetzungen, Gründe und bisherigen Ergebnisse solcher Bemühungen.
Insbesondere durch den steigenden Einsatz von Arbeitsplatzrechnern und leistungsstarken PCs, die über lokale Netzwerke miteinander kommunizieren, ist die Verteiltheit der Datenhaltung und der Kontrolle zu einem integralen Bestandteil in vielen Bereichen der Datenverarbeitung geworden. Beispielhaft aufgeführt seien hier die wachsende Bedeutung sogenannter Non-Standard-Datenbanksysteme (zum Beispiel bei CAD} oder auch der verteilten Files und Mail-Systeme. Nicht zuletzt auf der Betriebssystemebene selber können in einer verteilten Umgebung Dienstleistungen wie die Aufrechterhaltung eines konsistenten Namensraumes mit Hilfe von Transaktionen bereitgestellt werden. Aus dieser Entwicklung ergibt sich ganz zwangsläufig, daß zur Zeit weltweit in Forschung und Entwicklung eifrig an verteilten Betriebssystemen gearbeitet wird, die die konzeptionellen Grundlagen eines generellen Transaktionsmanagements als gemeinsame Basis zur Verfügung stellen.
Die Implementierung von Konsistenzerhaltungsmechanismen sowie von Maßnahmen zur Wiederherstellung von Systemzuständen zieht unvermeidlich eine Einschränkung der möglichen Parallelität und damit der Systemleistung nach sich. Außerdem werden zusätzliche Betriebsmittel gebunden. Nun wird dieser Trade-off durch die Verlagerung in die Betriebssystemebene noch verstärkt, da die Implementierung von Transaktionen nun nicht mehr auf eine bestimmte Anwendung hin optimiert werden kann. Also wird eine erheblich höhere Flexibilität der bereitzustellenden Mechanismen erforderlich. Die bisherigen Realisierungen in kommerziellen Datenbanksystemen trugen den dortigen Randbedingungen in besonderer Weise Rechnung und sind deshalb nicht komplett übertragbar.
Die Einhaltung des Konsistenzkriteriums "Serialisierbarkeit wird mit Hilfe der Strategie des "Locking auf der Datenbankebene implementiert: In einer Transaktion benötigte Daten bleiben dabei so lange für andere Aktivitäten gesperrt, bis die Transaktion beendet ist. Dies gilt auch dann, wenn die Daten schon lange vor Beendigung der Transaktion nicht mehr benötigt, das heißt nicht mehr referiert wurden. Weiterhin führen dort innerhalb einer Transaktion auftretende unerwünschte Ergebnisse, zum Beispiel Fehler, zu einem Abbruch der gesamten Transaktion und damit zu einem Widerruf aller bis dato erfolgen Operationen. Es ergibt sich unmittelbar, daß insbesondere für sogenannte langlebige Transaktionen, wie sie häufig im Designbereich oder in Büro- beziehungsweise Verwaltungssystemen vorkommen, diese Vorgehensweise nicht mehr akzeptabel wäre. Dies soll am Beispiel der Vorbereitung einer Sitzung verdeutlicht werden.
Wichtigste Aufgabe ist zunächst die Festsetzung eines Termins. Die dazu notwendigen Aktivitäten können wie folgt unterteilt werden: Der Organisator des Treffens erstellt eine Liste von Terminvorschlägen und sendet diese den Teilnehmern zu. Jeder Teilnehmer seinerseits benennt daraus diejenigen Termine die für ihn akzeptabel sind. Abhängig von den eingegangenen Antworten setzt der Organisator einen Termin fest und lädt dazu formell ein. Die Teilnehmer bestätigen den Erhalt der Einladung und sagen verbindlich zu.
Zusätzlich seien in diesem Beispiel noch einige Schritte aufgeführt, die parallel zu einigen der oben genannten ablaufen könnten: Reservierung des Konferenzraumes für den betreffenden Termin, Abwicklung des Dienstreisegenehmigungsverfahrens bei den auswärtigen Teilnehmern sowie Reisebuchung für den vorgesehenen Termin.
Die gesamte Sitzungsvorbereitung soll im Rahmen einer Transaktion ablaufen, das heißt entweder findet als Resultat die geplante Sitzung zu einem bestimmten Termin statt, oder die Bemühungen darum sind zumindest vorerst gescheitert und es müßte ein neuer Anlauf unternommen werden. Angenommen, es würde bei der Abwicklung der ersten Schritte etwas nicht wie geplant ablaufen, zum Beispiel der vorgesehene Konferenzraum ist für den betreffenden Termin schon belegt, oder die Dienstreise wird wegen eines damit konkurrierenden Termins nicht genehmigt beziehungsweise der vorgesehene Flug ist schon ausgebucht. In all diesen Fällen würde dies, zunächst jedenfalls, nicht direkt zu einem Abbruch der Sitzungsvorbereitung führen, was im bisherigen Transaktionskonzept die logische Folge gewesen wäre. Statt dessen würde in diesem Beispiel zunächst nach gangbaren Alternativen gesucht, die es doch noch ermöglichen, die Sitzung am bereits vereinbarten Termin stattfinden zu lassen. Denkbare wäre hier die mögliche Nutzung eines anderen Konferenzraumes oder eine eventuelle Verlegung des Konkurrenztermins beziehungsweise die Inanspruchnahme eines anderen Verkehrsmittels.
Um aber eine solche Vorgehensweise realisieren zu können, müssen Transaktionen auch schachtelbar sein. Die Einführung von geschachtelten Transaktionen macht es möglich, daß auch Teile der Gesamtaktivität einer Transaktion widerrufen und auf frühere Zustände zurückgesetzt werden können. Allerdings führt dieser Ansatz zu Konsequenzen für Konzept und Implementierung, bezogen auf die in der ersten Folge beschriebenen herkömmlichen Vorgehensweise.
Vorläufiger Endzustand muß eingeführt werden
Eine Subtransaktion kann nun nicht mehr durch das Zwei-Phasen-Commit-Protokoll beendet werden. Dies würde nämlich bedeuten, daß bei einem späteren Abbruch einer übergeordneten Transaktion diese nicht mehr vollständig zurückgesetzt werden kann. Denn der durch die Subtransaktion verursachte Zustandswechsel wurde ja schon durch das Commit endgültig gemacht. Damit wäre aber die Atomarität verletzt. Es muß also so etwas wie ein vorläufiger Endzustand eingeführt werden, der auch einen späteren Widerruf nicht ausschließt. Dadurch entstehen wiederum Auswirkungen auf die Synchronisation. Nach welchen Kriterien sollen mehrere Subtransaktionen miteinander synchronisiert werden? Was geschieht mit den von einer Substransaktion gesperrten Objekten nach ihrer Beendigung?
Dieses Beispiel zeigt auch, daß das in Datenbanken angewandte Verfahren, zugegriffene Daten bis zum Ende der Transaktion für alle anderen Aktivitäten zu sperren, nicht verallgemeinert werden kann. In diesem Fall hieße dies unter anderem, die Belegungsliste des Konferenzraumes oder die Terminkalender der betroffenen Teilnehmer für andere Zwecke als diese Transaktion bis zu deren Ende zu sperren. In der Tat können jedoch die einzelnen Terminkalender nach der Einigung auf einen bestimmten Termin für andere Eintragungen freigegeben werden. Um dies zu ermöglichen, muß das bisherige, relativ einfache Sperrverfahren entsprechend modifiziert werden. Der dabei anfallende Mehraufwand scheint aber durch die damit verbundene Effizienzsteigerung mehr als ausgeglichen.
Allerdings wird durch solch eine vorzeitige Freigabe von Daten die Wiederherstellung (Recovery) von Daten nach dem Scheitern einer Transaktion erheblich beeinflußt. Bisher war dazu lediglich das Wiedereinsetzen der mittels Kopie gespeicherten alten Zustände (Werte) der Daten notwendig, die durch diese eine Transaktion modifiziert worden waren. Die Auswirkungen auf das Gesamtsystem waren also vernachlässigbar gering. Dies gilt nun leider nicht mehr, da der wieder rückgängig und damit ungültig gemachte Wert dieser Daten inzwischen von anderen Transaktionen gelesen worden sein könnte. In der Konsequenz sind auch diese Transaktionen ungeschehen zu machen. Daraus ergibt sich übrigens, daß alle Transaktionen, welche auf vorzeitig freigegebene Daten zugegriffen haben, erst dann in den Commitzustand eintreten können, wenn dies für die erste Transaktion schon geschehen ist.
Es entsteht also das zusätzliche Problem, die so entstehenden Abhängigkeiten zwischen verschiedenen Transaktionen ebenfalls in irgendeiner Art und Weise zu vermerken. Nur dann kann im Falle des Scheiterns einer einzelnen Transaktion festgestellt werden, wer oder was davon betroffen ist. Es müssen also entsprechende Datenstrukturen sowie die dazugehörigen Algorithmen entwickelt werden. Vorliegende Auswertungen von Messungen an Labormodellen deuten darauf hin, daß es aus Effizienzgründen notwendig wird, die Abwicklung der komplexer gewordenen Recovery nunmehr speziell dafür vorgesehenen Prozessoren zu übertragen. Diese könnten in einer verteilten Systemarchitektur parallel zu den eigentlichen, die Transaktion ausführenden Prozessen ablaufen.
Parallelverarbeitung schafft mehr Effizienz
Eine zweite Möglichkeit gewinnt zunehmend an Bedeutung: Dabei geht es darum, die Synchronisation des Zugriffs auf gemeinsam benutzte Daten unter Ausnutzung von Parallelverarbeitung effizienter zu gestalten und damit den Durchsatz zu erhöhen. Der erreichbare Grad an Parallelität ist abhängig von der Detailliertheit der Information über die Semantik der auf den Daten arbeitenden Operationen. Zur näheren Erläuterung dieses Zusammenhangs dient das angeführte Beispiel, insbesondere die Möglichkeiten der Synchronisierung von Zugriffen auf den Terminkalender:
Hätte man keine Informationen über die Semantik der mit einem Zugriff einhergehenden Operation auf dem Terminkalender, müßte man zur restriktiven Form greifen, nämlich dem exklusiven Zugriffsrecht. Dies würde bedeuten, daß zu jeder Zeit immer nur eine Instanz berechtigt ist, auf dieses Objekt zuzugreifen. In Datenbanksystemen wird üblicherweise nach der Lese/Schreib-Semantik verfahren, das heißt, man kann zwischen lesenden und schreibenden Operationen unterscheiden. Als Folge davon ist es dann möglich, daß mehrere Instanzen gleichzeitig ein Leserecht auf demselben Objekt besitzen, ohne daß die Serialisierbarkeit verletzt wird. Ursache dafür ist, daß Leseoperationen verschiedener Transaktionen beliebig in ihrer Reihenfolge vertuschbar sind, ohne daß sich etwas am Resultat ändert.
Operationen können gleichzeitig ablaufen
Auf das Beispiel Terminkalender zurückkommend, könnte man aber die Operationen noch genauer spezifizieren, beispielsweise: "Zeige Tagesblatt", "Zeige Wochenübersicht", "Notiere Merkeintrag", "Trage Termin ein", "Lösche Termin".
Offensichtlich fallen sowohl das Notieren von Merkeinträgen (zum Beispiel als Erinnerungsstütze für ein noch zu führendes Telefongespräch) als auch das Eintragen beziehungsweise Löschen von Terminen in die Kategorie der Schreiboperationen. Auf dieser Ebene würden sich also Zugriffe auf den Terminkalender zwecks Notierung eines Merkantrags sowie zum Löschen eines Termins wechselseitig ausschließen. Legt man jedoch dieses konkrete Beispiel zugrunde, ist dies nicht notwendig. Beide Operationen können parallel ablaufen, da sie sich gegenseitig nicht beeinflussen. Somit ist die Reihenfolge untereinander beliebig, das heißt, die Serialisierbarkeit kann nicht verletzt werden.
Objektorientierter Ansatz hilft bei Problemlösung
Konzeptionell wird eine solche Vorgehensweise als objektorientiert bezeichnet. Unter einem Objekt versteht man im allgemeinen ein Exemplar (eine Inkarnation) eines abstrakten Datentyps. Dieser besteht aus einer Menge von Daten und einer Anzahl von Operationen, welche allein diese Daten manipulieren dürfen. Die Operationen stellen die sichtbare Schnittstelle dar, charakterisieren den Typ des Objektes und werden deshalb auch als typspezifische Operationen bezeichnet.
Der objektorientierte Ansatz kann auch einen Beitrag zur Lösung einer Reihe weiterer Probleme liefern. Dazu gehört das sichere "Sharing" von Objekten durch einen wohldefinierten Zugriffsmechanismus. Typinkompatibilität läßt sich mit diesem Ansatz rechtzeitig erkennen, wodurch zum Beispiel das Multiplizieren einer Zahl mit einem Buchstabenzeichen verhindert wird. Außerdem kann man effizienzmindernde Plattenzugriffe drastisch verringern, indem Logging-Daten im virtuellen Adreßraum aufbewahrt werden. Last but not least können so die bisher auf Seiten (Pages) basierenden Sperreinheiten verfeinert werden.
*) Dr. Edgar Nett ist Projektleiter bei der Gesellschaft für Mathematik und Datenverarbeitung (GMD), Sankt Augustin.