11.3 Realisierungsaspekte

11.3.1 Transaktionsverwaltung

Die globale Transaktionsverwaltung verlangt von dem TP-Monitor vor allem die Durchführung eines verteilten Commit-Protokolls. Daneben diskutieren wir noch kurz, inwieweit die DB-Konsistenz und Isolation gewahrt bleiben.

Commit-Behandlung

Um die Alles-oder-Nichts-Eigenschaft einer verteilten Transaktion zu garantieren, müssen die TP-Monitore ein gemeinsames verteiltes Commit-Protokoll unterstützen. Die LDBS sind an dem Protokoll über die TP-Monitore indirekt beteiligt, so daß ein hierarchisches Commit-Protokoll (Kap. 7.2.3) erforderlich wird. Eine Erweiterung bei der LDBS-Realisierung betrifft damit die Notwendigkeit, eine Commit-Initiierung "von außen" zu unterstützen. Damit wird allerdings eine Verringerung der lokalen Autonomie in Kauf genommen, da der Commit-Koordinator auf einem anderen Rechner residieren kann, dessen Ausfall den Zugriff auf lokale Daten möglicherweise für unbestimmte Zeit blockiert.

Die Kooperation zwischen heterogenen TP-Monitoren sowie zwischen TP-Monitoren und LDBS verlangt natürlich die Einigung auf ein gemeinsames Commit-Protokoll. De-facto-Standard ist hierzu derzeit das hierarchische Zwei-Phasen-Commit-Protokoll innerhalb des SNA-Protokolls LU 6.2 von IBM. LU (Logical Unit) 6.2, auch APPC (Advanced Program-to-Program Communication) genannt, dient innerhalb von SNA zur transaktionsgeschützten Kommunikation zwischen gleichberechtigten Programmen [Gr83]. Eine sehr ähnliche Funktionalität wie LU 6.2 wird von dem neuen OSI-Standard TP (Transaction Processing) angeboten [GR93], der im X/Open-Standard zur verteilten Transaktionsverarbeitung vorgesehen ist (s.u.). LDBS, welche die XA-Schnittstelle von X/Open unterstützen, können in das Commit-Protokoll einbezogen werden.

Ein anderer "Ansatz" zur verteilten Transaktionsverwaltung, der vielfach von Systemen verfolgt wird, die kein globales Commit-Protokoll unterstützen, besteht darin, keine verteilten Änderungstransaktionen zuzulassen bzw. Änderungen auf höchstens einen Rechner zu beschränken. In diesem Fall ist nämlich zur Sicherstellung der Atomarität kein globales Commit-Protokoll erforderlich. Globale Serialisierbarkeit wird jedoch nicht erreicht, da die Synchronisation (z.B. Sperrfreigabe) zwischen Sub-Transaktionen unkoordiniert erfolgt (s. Übungsaufgaben). Dafür sind praktisch keine Erweiterungen zur Transaktionsverwaltung erforderlich und eine hohe Autonomie der LDBS bleibt erhalten.

In Client/Server-Transaktionssystemen besteht das Problem, daß Client-Rechner wie PCs und Workstations aufgrund ihrer Unzuverlässigkeit zur Commit-Koordinierung nicht verwendet werden sollten. Denn fallen sie während der kritischen Commit-Phase aus, sind Teile der am Commit beteiligten Datenbanken auf unbestimmte Zeit blockiert. Aus diesem Grund muß bei der Commit-Operation einer Client-Anwendung die Koordinatorfunktion auf einen der Server-Rechner migrieren [Pa91]. Eine solche Funktionalität wird bereits von einigen Systemen unterstützt.

Konsistenz und Isolation

Die Unterstützung des Commit-Protokolls durch die TP-Monitore und LDBS garantiert allein noch nicht die Einhaltung der ACID-Eigenschaften für verteilte Transaktionen, sondern lediglich die globale Atomarität (A) und Dauerhaftigkeit (D). Die Sicherstellung der globalen Datenbankkonsistenz (C) würde die automatische Überwachung LDBS-übergreifender Integritätsbedingungen erfordern. Dies kann ohne DBS-Unterstützung offenbar nicht erreicht werden, so daß bei fehlender Kooperation der LDBS die globale Integritätsüberwachung durch die Anwendungen vorzunehmen ist[51].

Etwas besser sieht es hinsichtlich der Isolation aus. Denn wie in [BST90] gezeigt, ist die globale Serialisierbarkeit der Transaktionsverarbeitung gewährleistet, wenn jedes der beteiligten LDBS neben dem gemeinsamen Zwei-Phasen-Commit-Protokoll ein striktes Zwei-Phasen-Sperrverfahren (lange Sperren) zur Synchronisation einsetzt. Die Auflösung globaler Deadlocks erfolgt dann am einfachsten mit einem Timeout-Verfahren. Jedoch selbst dann wird eine (einfache) Erweiterung der LDBS notwendig, wenn zur Auflösung lokaler Deadlocks ein anderes Verfahren verwendet wurde (z.B. explizite Erkennung von Deadlocks). Der Einfachheit des Timeout-Ansatzes stehen daneben potentielle Leistungsprobleme gegenüber (Kap. 8.5.3).

[51] Föderative DBS versuchen diese Aufgabe durch eine zusätzliche DBS-Komponente zwischen Anwendungen und LDBS zu lösen.