Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

21.06.1991 - 

Nicht Unix, sondern offene und verteilte Umgebungen sind das Ziel

Transaktionsverarbeitung in verteilten DV-Umgebungen

Noch immer gibt es Vorbehalte gegen den Einsatz des Unix-Betriebssystems in kommerziellen DV-Umgebungen. Anwendungen gibt es zwar inzwischen en masse, woran es jedoch mangelt, ist die Sicherheit bei umfangreichen Transaktionen. Jürgen Berg* beschreibt die Möglichkeiten und Grenzen der Transaktionsverarbeitung nicht nur für Unix im speziellen, sondern darüber hinaus für offene verteilte Umgebungen im allgemeinen.

Das Thema "verteilte Verarbeitung" ist nicht neu. Modelle verteilter Systeme, insbesondere verteilter Datenhaltungssysteme, gibt es schon seit einigen Jahren. Diese Modelle basierten jedoch zunächst auf der Annahme, daß die Verteilung innerhalb einer "geschlossenen Welt", zum Beispiel innerhalb der Produktpalette eines Herstellers, stattfindet.

Neue Technologien, wie schnellere Netzwerke, Glasfaserverkabelung, und ein Umdenken in Richtung offene Systeme haben jedoch auch hier zu einer Neubestimmung des Standortes geführt. Verteilung kann heute demnach auch bedeuten, daß zwar heterogene Systeme im Sinne der Interoperabilität zusammenwirken können, dafür aber eine eingeschränkte Portabilität von Anwendungen zwischen diesen Systemen in Kauf genommen werden muß.

Ein weiterer Schritt könnte die Schaffung der Interoperabilität und/oder Portabilität zwischen verschiedenen TP-Monitor-Systemen oder -Systemkomponenten sein. Solche Bemühungen werden aber nicht nur durch die üblichen Schnittstellen-Probleme, sondern durch die besonderen Schwierigkeiten behindert, die nur in einer heterogenen Umgebung vorkommen können.

Ein großer Teil der Unternehmensdaten wird immer noch traditionell, also zentral, gehalten und kontrolliert. Der in der DV-Welt permanent stattfindende Umbruch bewirkt momentan, daß der Benutzer Zugriff auf heterogene Systeme, wie Mainfraimes, PCs und Workstations unterschiedlicher Hersteller, benötigt. Applikationen, die auf unterschiedlichen Plattformen jeweils optimal laufen, sollen integriert werden oder zumindest miteinander kommunizieren können.

Die Kunden erwarten von den Herstellern Produkte und Konzepte, die diesen Anforderungen entsprechen. Sie müssen an dem Ziel ausgerichtet sein, daß heterogene Systemlandschaften dem Benutzer gegenüber wie ein geschlossenes System erscheinen. Jeder Anwender soll auf alle Ressourcen und Daten dieses Systems Zugriff haben, und zwar in einer Form, die die darunterliegenden Systemplattformen transparent, das heißt nicht wahrnehmbar, erscheinen läßt. Das bedeutet, daß das System selbst komplex und intelligent genug sein muß, um auch den Betrieb über weit voneinander entfernte Standorte zu gewährleisten.

In einer vereinfachten Sicht kann man sich eine ortsungebundene Umgebung als ein großes Betriebssystem vorstellen. Wie in lokalen Umgebungen setzt die "neue Welt" übergeordnete Komponenten voraus, die zum Beispiel die Kommunikation von Applikationen untereinander steuern oder Dateizugriffe im Multiuser-Betrieb serialisieren. Außerdem muß ein "Naming Services" dafür sorgen, daß ein Benutzer, der eine bestimmte Applikation, die auf einem entfernten Knoten im Netzwerk läuft, starten will, dies auch tun kann, selbst wenn er den besagten Netzwerkknoten gar nicht kennt.

Der Weg führt notwendig zu verteilten Umgebungen

Aus einem solchen Szenario ergibt sich zwangsläufig die Notwendigkeit verteilter Verarbeitung und Datenhaltung. Erste Realisierungen von Architekturen, welche diese Anforderungen unterstützen, sind bereits vorhanden. Bis zur Verwirklichung der gesamten Vision dürfte aber noch einige Zeit vergehen, da zu diesem Zweck Probleme gelöst werden müssen, die nicht nur technischer Natur sind, sondern vor allem mit der Akzeptanz und der Administration dieser Systeme zusammenhängen.

In der Unix-Welt ist das Ziel der "Offenheit" bisher wohl eindeutig am konsequentesten verfolgt worden, was allerdings nicht bedeutet, daß ein offenes System zwangsläufig nur durch eine Unix-Implementierung gewährleistet wird.

Das Öffnen bisher proprietärer Betriebssysteme zum Beispiel durch die Unterstützung von Posix-Schnittstellen ist ein Indiz dafür, daß dieser Weg auch mit anderen Plattformen möglich ist. Auf der Anwendungsseite werden auch in dieser offenen Welt transaktionsorientierte Lösungen eine immer größere Bedeutung erlangen.

Wenn auch momentan der Markt für Datenbanken und Transaktionsverarbeitung noch eindeutig von nicht an Unix orientierten Systemen dominiert wird, so hat das Multiuser-Betriebssystem doch aufgrund der zu erwartenden Entwicklungen gute Chancen, sich in diesem Bereich zu etablieren. Ein Zeitrahmen ist allerdings schwer vorhersagbar, da Produkte wie TP-Monitore oder Transaktions-Manager, aber auch Datenbanksysteme kein Eigenleben führen. So ist meist aus Performance-Gründen der Integrationsgrad mit dem Betriebssystem recht hoch. Hier gilt es für Unix, den Vorsprung der am Markt etablierten proprietären Betriebssysteme aufzuholen.

Sobald verläßliche Unix-basierte TP-Software auf breiter Ebene verfügbar ist, wird sich der Trend zum "Downsizing" wohl auch in dieser bisher von den Mainfraimes dominierten Anwendungsebene durchsetzen. Zumindest werden neue Applikationen dann nicht mehr unbedingt zu der bereits bestehenden Last der größeren Rechner addiert, sondern auf kleinere und mittlere Systeme ausgelagert. TPC-A Benchmarks zeigen bereits heute ein günstigeres Preis-Leistungs-Verhältnis dieser Systeme. Schon aus Gründen des Investitionsschutzes wird dabei den Großrechnern die Funktion als Backbone bleiben.

Eine Transaktion ist die Ausführung einer administrativen Funktion durch ein Programm unter Zugriff auf eine gemeinsame Datenbasis. Wesentlich dabei ist, daß sich eine abgebrochene Transaktion vollständig rückgängig machen lassen muß. Es wäre fatal, wenn etwa ein Geldautomat zwar eine bestimmte Summe abbucht 9 sie aber nicht auszahlt.

Wann eine Transaktion beginnt und endet, bestimmt der Systemdesigner, dies richtet sich nach den jeweiligen Geschäftsanforderungen. Wenn beispielsweise festgelegt ist, daß eine Reisebuchungstransaktion aus einer Flug- und Hotelbuchung besteht, dann erwartet der Anwender, daß in jedem Falle entweder Flug und Hotel bestätigt oder beide storniert werden. Es macht wenig Sinn, ein entferntes Hotel ohne den dazugehörenden Flug zu bestätigen.

In welcher Reihenfolge diese Buchungen vorgenommen werden, kann das System bestimmen. Da es die Transaktionsklammer kennt, sorgt es selbst dafür, daß bereits vorgenommene Teilbuchungen wieder rückgängig gemacht werden, wenn es nicht möglich sein sollte, die gesamte Transaktion wie definiert auszuführen. In diesem Zusammenhang wird auch vom "Acid Prinzip" gesprochen.

Acid steht für Atomicity (keine Teilmodifikationen), Consistency (Summengleichheit), Isolation (Benutzer sehen nicht die Teilmodifikationen, sondern nur das Transaktionsergebnis - also entweder die Flug- und Hotelreservierung oder den alten Zustand nach einem "Rollback", (wenn die Buchung gescheitert ist) und Durability (stellt sicher, daß auch eine erfolgreiche Buchung rückgängig zu machen ist, wenn ein Fehler im Datenbestand auftaucht).

Hinter dem Kürzel Acid verbergen sich also Anforderungen, die heute von den meisten DB/TP-Systemen in nicht verteilten Umgebungen erfüllt werden. Bereites dort sind sie jedoch Ursache für ein hohes Maß an Komplexität, insbesondere beim Rollback und bei der Datenwiederherstellung (Recovery) im Fehlerfall. Noch größer

werden die Herausforderungen in einer verteilten, heterogenen Welt mit einer globalen Datensicht, unterschiedlichen Rechner- und Betriebssystem-Architekturen, Datenbanken und TP-Systemen.

Verteilte Datenhaltung und verteilte Verarbeitung

Das Gebäude der verteilten Verarbeitung ruht auf zwei Pfeilern: verteilte Verarbeitung und verteilte Datenhaltung (siehe Abbildung 1). Im Inneren des Gebäudes finden wir, von unten nach oben, das Systemmodell einer typischen DB/TP-Anwendung, bestehend aus:

1) Die Benutzerschnittstelle wird in den meisten Fällen ein Terminal sein, kann aber auch, zum Beispiel bei technischen Applikationen, ein Roboter oder irgend eine andere Datenquelle sein.

2) Präsentationsdienste sind Forms- und Maskensysteme, mit deren Hilfe man TP-typische Visualisierungen des Benutzerdialoges vornehmen kann. 3) Die Applikation ist die Software, durch welche die entsprechenden Geschäftsabläufe abgewickelt werden (in der Regel vom Benutzer selbst entwickelt oder als SW Paket eingekauft), sowie entsprechende TP-Monitor-Steuerungsroutinen, also Systemsoftware der entsprechenden Hersteller.

4) Datenzugriffsroutinen sind zum Beispiel die in den Applikationen enthaltenen SQL-Routinen.

5) Der Ressource Manager, das ist entweder ein Datenbank-Management-System oder aber ein "normales" Dateisystem.

Verteilte Applikationen: Wenn man nun die Komponente 1 von den übrigen Komponenten 2 bis 5 trennt, dann hat man die einfachste Stufe der Verteilung erreicht, ein Terminal-Netzwerk. Da dies keine wirkliche Verteilung ist, verschieben wir die Trennlinie weiter nach oben, zwischen die Komponenten 2 und 3, so daß Benutzerschnittstelle und Präsentationsdienste von den restlichen Diensten getrennt werden.

Verwaltet zum Beispiel eine Niederlassung in Paris die zentrale Datenbank sowie den Schwerpunkt einer Applikation (Datenbankzugriffe, Business-Logik), während intelligente Workstations in Rom und Berlin die Präsentationsdienste leisten, dann erfährt die zentrale CPU eine erhebliche Entlastung. Der Grund: In einer TP-Anwendung werden typischerweise bis zu 65 Prozent der Benutzeraktionen für den Maskendialog aufgewendet, bevor ein Datenbankzugriff erfolgt.

Intelligente Maskensysteme, welche einen großen Teil der

Anwendungslogik, wie Validierungsprüfungen und Feldabhängigkeiten vornehmen können, sind Voraussetzung für die Effizienz eines solchen Systemdesign. Hier sind Systeme, die Standards unterstützen, am besten geeignet, den Anforderungen der Zukunft gerecht zu werden.

Ein in der Validierung befindlicher ANSI/ISO-Standard ist Fims (Forms Interface Management System). Eine moderne DB/TP-Entwicklungsumgebung bietet darüber hinaus dem Designer die Möglichkeit, die Entwicklungsphase unabhängig von dem späteren Einsatzspektrum des Systems zu gestalten. Mit anderen Worten: Ob die Präsentationsdienste später einmal zentral oder dezentral eingesetzt werden, darf auf die Applikation und deren Entwicklung keine Auswirkung haben.

Eine solche verteilte Losung stellt an die Administration höhere Ansprüche als eine zentrale Applikation. So müssen beispielsweise für das "Change Management" zusätzliche organisatorische Vorkehrungen getroffen werden, damit nicht etwa eine Änderung des Maskendesigns zu Problemen führt, weil nicht alle dezentralen Lokationen rechtzeitig mit der neuen Software versorgt wurden.

Weitere Möglichkeiten für die Verteilung von Anwendungen ist die logische Teilung einer Anwendung zwischen zwei Systemen, beispielsweise das Auslösen einer Transaktion durch eine andere Transaktion auf einem entfernten Rechner, also das Kommunizieren von Anwendungen untereinander. Als alternative Implementierungen dieser Funktionalität können "Peer to Peer", (etwa mit Hilfe des LU6.2-Protokolls), und "Request-Reply" (RPC) angesehen werden, aber auch "Qeueing" spielt in diesem Zusammenhang eine Rolle.

Der Begrriff RPC (Remote Procedure Call) ist am besten mit Unterprogramm-Technik beschrieben. Eine Prozedur A ruft eine Prozedur B, Prozedur B ruft Prozedur C, C kehrt zurück nach B, B kehrt zurück nach A. Dabei werden diverse Informationen (Parameter) zwischen den Beteiligten hin und her bewegt. Das Entscheidende ist, daß dies in einer starren Reihenfolge geschieht, entsprechend dem unter den Prozeduren herrschenden Aufrufalgorithmus.

In dieser Art der Konversation warten die anderen so lange, bis derjenige, dem das Wort erteilt wurde, ausgeredet hat. Peer to Peer dagegen gleicht mehr einer Diskussion, bei der viele Teilnehmer gleichzeitig reden (mit dem Unterschied, daß auch gleichzeitig zugehört und verstanden wird). In einer Peer-to-Peer Konversation können von einer Prozedur aus gleichzeitig mehrere Pfade zu (mehreren) anderen Prozeduren eröffnet werden, entweder nur als Pfade, auf denen Nachrichten überbracht, oder als Pfade, auf denen auch eine Antwort erwartet wird. Die Synchronisation wird dabei in der Regel durch Interrupts oder Exceptions vom Betriebssystem übernommen.

Das Verteilen von Datenbanken

Kommen wir zurück zu dem Gebäude der verteilten Transaktionsverarbeitung. Beginnend mit der Verschiebung der Trennlinie mitten durch die Komponente 3 und weiter zu den Komponenten 4 und 5 erfolgt der Übergang zu den verteilten Datenbanken. Auch hier wieder ein Anwendungsbeispiel: Von einer Workstation in Berlin wird eine Reisebuchung vorgenommen, welche Hotelaufenthalte in Paris und Rom vorsieht sowie die jeweiligen Flugbuchungen.

Im Gegensatz zum ersten Beispiel, in dem die Daten zentral in Paris gehalten wurden, liegen die jeweiligen Daten nun an dem Ort, wo sie benötigt werden. Für den Benutzer und die Applikation besteht nur ein logischer Datenbestand. In dieser Transaktion geschieht komprimiert folgendes:

- Update der Flugreservierung auf der Datenbank in Berlin,

- Update der Hotelbuchung auf der Pariser Datenbank,

- Update der Hotelbuchung auf der Datenbank in Rom.

Hier treffen wir wieder auf das eingangs erwähnte Acid-Prinzip. Außerdem wird die Problempalette noch durch verteilte Deadlocks und verteilte Optimizer erweitert. Das Vorhandensein entsprechender Management-Routinen ist ein Kriterium für ein echtes verteiltes DBMS.

Wie kann sichergestellt werden, daß entweder alle drei Datenbank-Veränderungen oder keine einzige durchgeführt wird, oder aber eine oder zwei bereits durchgeführte Änderungen rückgängig gemacht, werden, falls sich die dritte Änderung nicht durchfuhren läßt? In diesem Falle wäre es durchaus möglich, die Transaktion so zu gestalten, daß eine Bestätigung erfolgt, wenn mindestens eine Teilstrecke mit Übernachtung feststeht. Wie anfangs erwähnt, liegt dies in der Entscheidung des Systemdesigners.

Die Verarbeitungskonsistenz bei verteilten Transaktionen wird durch das "Two Phase Commit Protocol" (2PC) erreicht. Abbildung 2 zeigt die an einer verteilten Transaktion beteiligten Systemkomponenten.

Der Transaktions-Manager des Knotens, von dem aus die Transaktion gestartet wurde, fungiert immer als Koordinator. Er unterrichtet die beteiligten Knoten von den bevorstehenden Modifikationen, und erst, wenn alle in die Modifikation eingewilligt haben (alle haben auf die Prepare Phase mit einem Ready geantwortet), kann die Transaktion beendet werden. Dabei ist wichtig zu wissen, daß alle Datenbankänderungen bereits in der Vorbereitungsphase, also vor der Meldung "Ready", auf die Datenbank geschrieben werden. Damit garantiert das 2PC-Protokoll die Acid-Regeln sogar dann, wenn ein Knoten ausfällt.

Manueller Eingriff in das Geschehen

Fällt allerdings der Koordinator aus, dann muß abhängig vom Fehlerzeitpunkt eventuell manuell in das Geschehen eingegriffen werden. Hier ist der DB-Administrator (DBA) gefordert. Das kann zu administrativen Problemen führen, wenn in der entsprechenden Installation nicht genau festgelegt ist, wer in den jeweiligen Lokationen dafür verantwortlich ist und was in welcher Reihenfolge zu geschehen hat. Das 2PC-Protokoll führt genügend Aufzeichnungen, um den DBA zu unterstützen, eine sogenannte "Blocked Transaction" zu erkennen und die entsprechenden Maßnahmen einzuleiten.

Heutige Technik ist sehr wohl in der Lage, verteilte Anwendungen und verteilte Datenhaltung zu ermöglichen. Die Realisierung von sogenannten echten verteilten Datenbanksystemen im Sinne von C.J. Date (An Introduction to Database Systems, Volume II) in der geforderten Art ist aber noch nicht vollständig geschehen.

Transaktions-Monitor und Transaktions-Manager

In diesem Zusammenhang sei noch auf den Unterschied zwischen einem Transaktionsmonitor und einem Transaktions-Manager verwiesen:

a) Ein Transaktions-Monitor (wie ACMS von Digital, CICS von IBM oder Tuxecdo von AT&T)" stellt in der Regel eine komplette Transaktions-Entwicklungsumgebung dar, zusammen mit allen Komponenten, die erforderlich sind, um diese transaktionsorientierten Applikationen zu verwalten und ablauffähig zu gestalten (zum Beispiel das Management für Terminals, User, Applikationen, Dispatching und Scheduling). Ein Transaktions-Monitor ist im allgemeinen ein "Layered- oder System Produkt" und arbeitet eng mit dem Betriebssystem und einem Dateisystem zusammen.

b) Ein Transaktions-Manager kann Teil eines Transaktions-Monitors, aber auch Teil eines Betriebssystems sein, von wo aus er seine Systemdienste zur Verfügung stellt.

Aufgabe eines Transaktions-Managers ist in erster Linie die Überwachung des korrekten Ablaufes einer Transaktion, in unserem Beispiel also das Koordinieren einer Transaktion über mehrere Netzwerkknoten, indem er ein 2PC-Protokolls bereitstellt.

Die Verlagerung derartiger Funktionalität in eine tieferliegende Schicht wie das Betriebssystem hat den Vorteil, daß von hier aus verschiedene Datenbanksysteme und TP-Monitore direkt erreicht werden können, transparent für die Anwendung. Der Nachteil liegt vorerst noch darin, daß, solange sich Standards auf diesem Markt noch nicht etabliert haben, der Benutzer auf eine Herstellerwelt festgelegt ist. Speziell in diesem Bereich gibt es jedoch diverse Aktivitäten, die zu Veränderungen führen werden.

Standards machen Module austauschbar - im Prinzip

Heute ist es zwar prinzipiell möglich, DB-Systeme auszutauschen, die die SQL-Schnittstelle unterstützen. Kommen diese Systeme jedoch von unterschiedlichen Herstellern, dann wird es nicht ohne Modifikationen sämtlicher betroffener Anwendungen abgehen, weil nach wie vor jeder Hersteller sein Produkt mit besonderen Eigenschaften versieht. An dieser Situation dürfte sich aller Voraussicht nach in absehbarer Zeit wenig ändern. Verglichen mit der TP-Seite, ist dieser Zustand jedoch erträglich, da es hier momentan noch gar keinen Standard gibt, der es erlauben würde, irgendeine TP-Komponente auszutauschen.

Die Entwicklung von Standards geht jedoch voran. Zu nennen wären die Spezifikationen der X/Open-Gruppe und ISO/TP. Abbildung 3 zeigt, wo die einzelnen Standardkomponenten ansetzen.

- X/Open-TP enthält im wesentlichen die Beschreibung von APIs (Application Programming Interfaces). Zwischen Applikation und Transaktionsmonitor ist dies die sogenannte "tx-Schnittstelle", welche den Beginn und das Ende einer Transaktion beschreibt. Ein Transaktions-Manager, der dieses Application Program Interface (API) implementiert, kann sich zur Anwenderseite hin offen nennen.

Ebenso verhält es sich mit den APIs, die die Schnittstellen zwischen Transaktions-Manager (TM) und Communication Manager sowie zwischen TM und Datenbanksystem beschreiben.

Alle Komponenten, die diese Schnittstellen implementiert haben, sollten untereinander austauschbar sein. Die Kommunikation von einem TM beziehungsweise CM zum anderen von unterschiedlichen Herstellern wird durch eine Schnittstelle (Protokoll) ermöglicht, welches von der International Standard Organistaion (ISO) hervorgebracht wurde (ISO/TP). Diese ISO/TP-Schnittstelle ist Peer-to-Peer- orientiert und steht im Gegensatz zu anderen Bemühungen, welche ein (transactional) RPC-basiertes Protokoll favorisieren.

Einen weiteren Standardisierungsweg hat die japanische Post NTT (Nippon Telegraph and Telephone) zusammen mit DEC, Fujitsu, Hitachi und IBM beschnitten. Die Unternehmen gründeten ein Konsortium, welches damit beauftragt wurde, für die bei NTT vorkommende heterogene Systemlandschaft eine Integrationsarchitektur mit der Bezeichnung MIA zu definieren und diese Architektur mit entsprechenden Produkten in größtmöglicher Anlehnung an Standards zu versehen. Als Schnittstelle zwischen Applikation und Transaktions-Manager wurde hier eine Standard Task Definition Language (STDL) ausgewählt, die auf einem bereits bestehenden Produkt aufbaut, nämlich auf ACMS (Application Control and Management System), einem Transaktionsmonitor von DEC.

Im Unterschied zu X/Opens TP, wo die tx-Schnittstelle nur die TP-Semantik - welche in ein 3GL-Programm (Cobol, C) eingebettet werden kann - beschreibt, handelt es sich bei MIA-STDL um eine bereits vorhandene umfangreiche Implementierung einer TP-spezifischen strukturierten Hochsprache.

Die Kommunikation von einem TP-System (Communication Manager) zum anderen wird in dieser Architektur voraussichtlich nicht Peer-to-Peer, sondern RPC-basiert sein. Diese Standardisierungaktivitäten bedeuten einen wesentlichen Schritt in Richtung offene TP-Systeme.

Da die Begriffe "Unix" und "offene Systeme" eng miteinander verwandt sind, werden die ersten Produkte, die offene Schnittstellen implementieren, vermutlich auf diesem Betriebssystem basieren, andere Plattformen dürften folgen. Es ist zu vermuten, daß die TP-Standards eine ähnliche Entwicklung wie der SQL-Standard durchlaufen, so daß die Anwender ihre Applikationen um einen "Kernmonitor", der in den meisten Fällen vom Haupt-Hardware-Lieferanten Stammt, aufbauen können.

Dieser Monitor wird neben einer Reihe von sicherlich reizvollen proprietären Eigenschaften auch einige Standardschnittstellen unterstützen müssen, um eine gewisse Interoperabilität zur Verfügung stellen zu können. Daneben sind die Datenbankhersteller gefordert, ihre Produkte den Erwartungen, die an echte verteilte Systeme gestellt werden, anzupassen. Das wiederum fordert vom Anwender noch mehr Flexibilität, administratives Umdenken und eine noch höhere Eigenverantwortung beim Systemdesign.

Auf dem TP-Sektor ist eine längerfristige Auseinandersetzung zwischen De-facto-Standards wie CICS von IBM und neuen "Computing Styles", wie Tuxedo von AT&T, zu erwarten.

Zum Abschluß soll ein kurzer Ausblick in eine komplexe und komplizierte Problematik verdeutlichen, daß sich mit neuen Techniken auch ebenso neue Herausforderungen und Probleme einfinden und daß anfangs beschriebene Prinzip der Atomicity (das A von Acid) in einer verteilten, heterogenen Welt fraglich erscheint:

Man stelle sich vor, eine Transaktion umfaßt 20, 30, 100 oder mehr Lokationen, von denen der größte Teil von unterschiedlicher Hardwareherstellern stammt. Wenn nun beispielsweise bei Lokation 94 nach, sagen wir, sechs Stunden ein Fehler auftritt, dann würde allein das Zurücksetzen der bisherigen Änderungen mindestens noch einmal sechs Stunden in Anspruch nehmen.

In solchen Fällen ist es sinnvoll, bisher durchgeführte Änderungen nicht zurückzusetzen. Aber wie soll der Kontext gehalten werden, wie soll wiederaufgesetzt werden? In diesem Zusammenhang wird über sogenannte übergeordnete Transaktionen gesprochen, die diese Funktionalität übernehmen könnten.

*Jürgen Berg ist Technologieberater bei Digital Equipment GmbH, Unterföhring bei München.