DE10045437A1

DE10045437A1 - Ein erweiterter Transaktionsprozessor zur Beendigung von Transaktionen vor deren Abschluss

Info

Publication number: DE10045437A1
Application number: DE2000145437
Authority: DE
Inventors: John Anthony Beaven; Amanda Elisabeth Chessell; Catherine Griffin; Iain Stuart Caldwell Houston; Martin Mulholland; Ian Robinson; David John Vines
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2000-09-14
Filing date: 2000-09-14
Publication date: 2002-04-04

Abstract

Eine Vorrichtung zur Koordination einer oder mehrerer erweiterter Transaktionen wird beschrieben, wobei die genannte Vorrichtung folgendes umfasst: Mittel, um Eingänge zu empfangen, die Ergebnisse von einem Transaktionsanwender anzeigen; Mittel zum Empfangen von Eingängen, die Ergebnisse einer oder mehrerer Sub-Transaktionen anzeigen; ansprechend auf die genannten Eingänge, Mittel, um ein Ergebnis für die genannte erweiterte Transaktion zu ermitteln; und ansprechend auf das genannte Ergebnis, Mittel, um eine oder mehrere Sub-Transaktionen vor der Abschlussverarbeitung zu beenden; wobei die genannte erweiterte Transaktion wählbar, ohne Abschlussverarbeitung aller Sub-Transaktionen, bis zum Abschluss geführt werden kann.

Description

Verwandte Patentanmeldungen

Die vorliegende Erfindung ist verwandt mit der U.S. Patentanmeldung mit der IBM-Registernummer UK999097 und dem Titel "A Replaceable Outcome Decider", die gleichzeitig mit der vorliegenden Anmeldung eingereicht wurde.

Technisches Gebiet der Erfindung

Die vorliegende Erfindung betrifft das Gebiet der Transaktionsverarbeitung und im einzelnen die erweiterte Transaktionsverarbeitungsumgebung.

Hintergrund der Erfindung

Der Begriff "Transaktion" wird im Bereich der Datenverarbeitung als Bezeichnung für einen bestimmten Teil eines Datenverarbeitungsprozesses verwendet, der über eine notwendige Einheit verfügen muss. Wenn beispielsweise Geld von einem Geldautomaten abgehoben wird, besteht die Datenverarbeitungsaufgabe aus mehreren Elementen. Jedes dieser Elemente muss jedoch abgearbeitet werden, damit die Transaktion abgeschlossen ist. Die Identität des Benutzers muss überprüft werden, das Geld muss ausgegeben werden, und das Konto des Benutzers muss aktualisiert werden, so dass der neue Saldo des Kontos nach der Transaktion reflektiert wird, usw. Wenn der Geldautomat leer ist oder wenn ein anderer Fehler auftritt, so dass es nicht zur Geldausgabe kommt, muss auch das Konto des Benutzers nicht aktualisiert werden oder, wenn das Konto bereits vor dem Auftreten der Funktionsstörung aktualisiert wurde, muss diese Buchung rückgängig gemacht und das Konto in den vorherigen Zustand zurückversetzt werden.

Im Bereich der Transaktionsverarbeitung müssen die Transaktionen also generell über die bekannten ACID- Eigenschaften verfügen. ACID ist ein Akronym und steht für die vier Eigenschaften einer Transaktion: Atomicity, Consistency, Isolation und Durability. Atomicity verlangt, dass entweder alle Operationen oder keine Operation einer Transaktion ausgeführt werden müssen. Consistency verlangt, dass eine Transaktion die Konsistenz der Datenbank sicherstellen muss. Isolation verlangt, dass bei einer Transaktion nicht die Zwischenergebnisse einer anderen Transaktion gelesen werden dürfen. Durability bedeutet, dass die Ergebnisse einer verbindlichen Transaktion permanent sein müssen. Hintergrundinformationen über die ACID-Eigenschaften finden sich in Transaction Processing: Concepts and Techniques, J. Gray und A. Reuter.

Bei einer herkömmlichen Transaktion, die über die ACID- Eigenschaften verfügt, wird das Ergebnis der Transaktion (unabhängig davon, ob diese abgeschlossen oder zurückgesetzt wird) ermittelt, indem ein Satz von "Stimmen" oder Anforderungen von der Anwendung, welche die Transaktion verwendet, und den Ressourcen (oder den die Ressourcen besitzenden Anwendungen), die an der Transaktion beteiligt sind, gesammelt wird. In konventionellen Transaktionsverarbeitungsumgebungen werden diese Funktionen von einem syncpoint (Synchronisationspunkt)-Manager oder einem Fehlerbehebungsmanager verwaltet, einem spezialisierten Programmelement, mit dem die "Stimmen" oder Anforderungen der an der Transaktion Beteiligten gesammelt und entsprechend einer gewöhnlich festen, für das System oder die Anwendung geltende Regel bearbeitet werden. Diese Funktion ist klar begrenzt, und zwar insofern, als die verfügbaren Auswahlmöglichkeiten als "go or no-go", als Commit oder Rollback der Ausführung, gekennzeichnet werden können. Dies ist in der unitären ACID-Transaktionsumgebung angebracht.

Natürlich gibt es komplexere geschäftliche Umgebungen, bei denen andere Merkmale als bei diesem relativ einfachen unitären Transaktionsmodell erforderlich sind. Diese sind Gegenstand ständiger Studien und Forschungen. Hintergrundinformationen zu komplexeren Transaktionsumgebungen finden sich in Database Transaction Models, Ahmed K. Elmagarmid, ed., und Advanced Transaction Models and Architectures, Jajodia und Kerschberg, eds. Zu den realen Beispielen gehört beispielsweise eine Ferienbuchung, an der möglicherweise mehrere Transaktionen für die Buchung von Flügen und das Mieten von Autos, das Reservieren von Hotelzimmern usw. beteiligt sind. Für solche Fälle ist möglicherweise das einfache Modell einer Transaktion, die entweder komplett funktioniert oder komplett fehlschlägt, nicht das beste Modell. Hier kann es sinnvoller sein, innerhalb der Transaktionssemantik über eine gewisse Flexibilität zu verfügen, so dass partielle Erfolge und Fehler möglich sind, eine vorläufige Buchung fortgesetzt und eine andere rückgängig gemacht werden kann, und so weiter. Andererseits ist bei einer solchen erweiterten Transaktion wahrscheinlich eine längere Bearbeitungszeit notwendig und es wäre daher unsinnig, dass die Transaktion die Ressourcen, die zur Gewährleistung der Datenintegrität gesperrt werden, für diese lange Bearbeitungszeit blockiert.

Anwendungen für große Unternehmen, die mit Hilfe eines Online Transaction Processing (OLTP)-Systems implementiert wurden, verwenden typischerweise eine Reihe einzelner ACID- Transaktionen, um eine Funktion zu implementieren, die als komplexe, jedoch kohärente Aktualisierung der Geschäftsdaten betrachtet wird. Aufgrund gemeinsam genutzter Daten und Ressourcen in der OLTP-Umgebung ist es nicht möglich, die geschäftliche Transaktion einfach als eine einzelne ACID- Transaktion zu implementieren. In einer solchen Struktur gibt es noch eine gewisse Entsprechung für den Syncpoint- oder Fehlerbehebungsmanager der konventionellen Umgebung. Seine Fähigkeiten müssen jedoch erweitert werden, um eine flexiblere Verarbeitung zu ermöglichen, als es mit dem einfachen "Commit or Rollback"-Modell der herkömmlichen Umgebung möglich wäre.

Eine weitere Problemebene bei der Verwaltung von Transaktionen ergibt sich, weil sich der Trend zum automatischen Einsatz flexibler Datenverarbeitungskomponenten in Reaktion auf abstrakte High-level-Modelle von Geschäftsvorgängen weiter fortsetzt. Eine solche Umgebung wird beschrieben in Enterprise Java Beans Technology von Anne Thomas (veröffentlicht von der Patricia Seybold Group). In einer solchen Umgebung wird durch den Abstraktionsgrad des Vorgangs, in dem flexible Komponenten mit einem in Echtzeit laufenden Informationsverarbeitungssystem kombiniert werden, das Problem einer genauen Kontrolle der einzelnen Transaktionen und Transaktionselemente, mit all ihren Beziehungen zu heterogenen Ressourcen, extrem schwierig.

In jedem Fall gibt es in Umgebungen mit erweiterter Transaktionsverarbeitung das Problem, dass ein Beenden verschachtelter Sub-Transaktionen, die nach ihrer Einleitung und teilweisen Ausführung für den Abschluss der erweiterten Transaktion als Ganzes nicht erforderlich sind, nicht möglich ist.

Zusammenfassung der Erfindung

Die vorliegende Erfindung stellt daher, in einem ersten Aspekt, eine Vorrichtung bereit zur Koordination einer erweiterten Transaktion, die mindestens eine Sub-Transaktion umfasst, wobei die genannte Vorrichtung folgendes umfasst: Mittel zum Empfangen eines Eingangs, der ein Ergebnis einer Benutzertransaktion anzeigt; Mittel zum Empfangen eines Eingangs, der ein Ergebnis mindestens einer Sub-Transaktion anzeigt; reagierend auf die genannten Eingänge, Mittel, um ein Ergebnis für die genannte erweiterte Transaktion zu ermitteln; und, reagierend auf das genannte Ergebnis, Mittel zur programmierbaren Auswahl der Beendigung einer oder mehrerer Sub-Transaktionen vor der Abschlussverarbeitung der genannten Sub-Transaktionen; wodurch die genannte erweiterte Transaktion selektiv in der Lage ist, die Transaktion zu beenden, ohne dass alle Sub-Transaktionen beendet werden müssen.

Die Vorrichtung des ersten Aspektes ist vorzugsweise weiter gekennzeichnet dadurch, dass die genannten Eingänge, die bestimmte Ergebnisse anzeigen, Indikatoren für den Erfolg bzw. Nichterfolg der genannten einen oder mehreren Sub- Transaktionen enthalten.

Die Vorrichtung des ersten Aspekts ist vorzugsweise weiter dadurch gekennzeichnet, dass die genannten Eingänge folgendes umfassen: Commit-Anforderungen; und Rollback-Anforderungen.

Die Vorrichtung des ersten Aspekts ist vorzugsweise weiter dadurch gekennzeichnet, dass das genannte Mittel zur Ermittlung eines Ergebnisses über Programme änderbare Abbildungsmittel umfasst. Vorzugsweise ist die Vorrichtung außerdem dadurch gekennzeichnet, dass das genannte Mittel zur Ermittlung eines Ergebnisses eine Abbildungstabelle umfasst. Vorzugsweise ist die Vorrichtung weiterhin auch dadurch gekennzeichnet, dass das genannte Mittel zur Ermittlung eines Ergebnisses ein über Programme änderbares Ergebnisverarbeitungsmittel umfasst.

In einem zweiten Aspekt stellt die vorliegende Erfindung eine Methode bereit zur Koordinierung einer erweiterten Transaktion, die über mindestens eine Sub-Transaktion verfügt, wobei die genannte Methode folgende Schritte umfasst: Empfangen eines Eingangs, der das Ergebnis einer Benutzertransaktion anzeigt; Empfangen eines Eingangs, der ein Ergebnis mindestens einer Sub-Transaktion anzeigt; reagierend auf die genannten Eingänge, Ermitteln eines Ergebnisses für die genannte erweiterte Transaktion; reagierend auf den genannten Schritt des Ermittelns eines Ergebnisses, programmierbares Auswählen, ob eine oder mehrere Sub-Transaktionen beendet werden, bevor die Verarbeitung der genannten Sub-Transaktion abgeschlossen ist; und Beenden der genannten einen oder mehreren Sub-Transaktionen; wodurch die genannte erweiterte Transaktion selektiv in die Lage versetzt wird, die Transaktion abzuschließen, ohne dass alle Sub- Transaktionen abgeschlossen werden müssen.

In einem dritten Aspekt stellt die vorliegende Erfindung ein Computer-Programmprodukt bereit zur Koordinierung einer oder mehrerer erweiterter Transaktionen, wobei das genannte Computer-Programmprodukt Computer-Programmbefehle umfasst, die auf einem computerlesbaren Speichermedium gespeichert sind und die, wenn sie in einen Computer geladen und ausgeführt werden, bewirken, dass ein Computer die Schritte der Methode des zweiten Aspekts ausführt.

Die vorliegende Erfindung hat daher in einem Transaktionsverarbeitungssystem den Vorteil, erweiterte Transaktionen flexibler zu koordinieren, als es bisher möglich war, indem ein Gesamtergebnis für die erweiterte Transaktion ermittelt werden kann, ohne dass alle verschachtelten Sub-Transaktionen abgeschlossen werden müssen und ohne dass die Eingänge Ergebnisse aller verschachtelten Sub-Transaktionen enthalten müssen. Indem es möglich ist, bereits zu einem frühen Zeitpunkt ein Ergebnis zu ermitteln und die übrigen verschachtelten Sub-Transaktionen vor ihrer endgültigen Verarbeitung zu beenden, bietet die vorliegende Erfindung den Vorteil, gleichzeitig die Ausführung mehrerer alternativer Aufgaben mit äquivalentem Ergebniswert versuchen zu können, so dass der "Gewinner" dann schließlich zum Abschluss gebracht werden kann (beispielsweise Änderungen in einer Datenbank), während der "Verlierer" durch frühzeitige Beendigung an einem Abschluss gehindert wird.

Kurze Beschreibung der Zeichnungen

Ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung soll nun anhand eines Beispiels und unter Bezugnahme auf die Zeichnungen beschrieben werden. Es zeigt;

Fig. 1 ein Datenverarbeitungssystem eines bevorzugten Ausführungsbeispiels, bei dem die Anforderungs- und Ergebnisbeispiele als Datenfluss dargestellt sind; und

Fig. 2 ein Flussbild mit den Schritten einer Methode gemäß einem bevorzugten Ausführungsbeispiel.

Fig. 3 ein Datenverarbeitungssystem eines bevorzugten Ausführungsbeispiels, das über einen austauschbaren Ergebnisentscheider verfügt, mit Anforderungs-, Verarbeitungs- und Ergebnisbeispielen.

Ausführliche Beschreibung eines bevorzugten Ausführungsbeispiels

In Fig. 1 läuft in einem Verarbeitungssystem (100) eine erweiterte Transaktion (101), umfassend eine Benutzertransaktion (102) und ihre beiden verschachtelten Sub-Transaktionen (104, 106). Die Benutzertransaktion (102) stellt einen Eingang (108) bereit, der dem Transaktionskoordinator (112) ein Ergebnis (z. B. "Request Commit" oder "Request Rollback") anzeigt. Auch die Sub-Transaktion (104) stellt einen Eingang (110) bereit, der dem Transaktionskoordinator (112) ein Ergebnis (z. B. wieder "Request Commit" oder "Request-Rollback") anzeigt. In dem vorliegenden Beispiel setzt die Sub-Transaktion (106) die Verarbeitung ohne Erzeugen eines Ergebnisses fort.

Der Transaktionskoordinator (112) akzeptiert Ergebnisse (108, 110) und verarbeitet diese, um ein koordiniertes Ergebnis zu erzeugen. Das koordinierte Ergebnis kann beispielsweise auf der Benutzung eines flexibel programmierbaren, austauschbaren Ergebnisentscheiders basieren, wie er in Fig. 3 gezeigt wird.

Alternativ kann das koordinierte Ergebnis durch Verwenden eines in der Technik hinlänglich bekannten Syncpoint- und Fehlerbehebungsmanagers ermittelt werden. In diesem Fall werden diejenigen Sub-Transaktionen, die ohne Abschlussverarbeitung beendet werden können, bei dem Syncpoint-Manager nicht als Teilnehmer an der Ergebnisentscheidung für die erweiterte Transaktion registriert.

In jedem Fall wurde in dem bevorzugten Ausführungsbeispiel der Transaktionskoordinator über das Programm darauf vorbereitet, Eingänge (108, 110) zu akzeptieren, um ein Gesamtergebnis für die Benutzertransaktion (102) und die verschachtelten Sub-Transaktionen (104, 106) vorzubereiten. In Fig. 1 muss die Sub-Transaktion (106) nicht abgeschlossen werden, damit die erweiterte Transaktion (101) ein Gesamtergebnis hat. Dies entweder, weil bei Verwendung eines bekannten Syncpoint- und Fehlerbehebungsmanagers die Sub- Transaktion (106) nicht als Teilnehmer am Ergebnis der erweiterten Transaktion registriert wurde, oder weil es sich bei Verwendung des flexiblen Ergebnisentscheiders um eine Sub-Transaktion aus einer Gruppe alternativer oder optionaler Sub-Transaktionen handelt, von denen eine oder mehrere nicht abgeschlossen werden müssen. Wenn beispielsweise ein flexibler Ergebnisentscheider in einem Ferienbuchungssystem eingesetzt wird, kann es wünschenswert sein, zwei Sub- Transaktionen auszuführen um zu versuchen, ein Mietauto zu buchen, jedoch dem Transaktionsprozessor über das Programm anzuzeigen, dass nur eine der Sub-Transaktionen erfolgreich sein muss, damit die erweiterte Transaktion, nämlich das Buchen eines Urlaubs, als abgeschlossen gilt.

Der Transaktionskoordinator (112) stellt dem Transaktionsverarbeitungssystem (100) das Ergebnis (114) wie üblich und wie in der Technik der Transaktionsverarbeitung bekannt ist zur Verfügung. In dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung wird jedoch das Ergebnis (114) auch als Eingang in einen Terminator- Prozessor (116) akzeptiert, der die Sub-Transaktion (106) vor ihrer Abschlussverarbeitung beendet. Der Terminator-Prozessor (116) kann dies tun, wie in Fig. 1 gezeigt wird, indem er einen Befehl "beenden" als spezifischen Eingang (118) an die Sub-Transaktion (106) ausgibt. Alternativ kann er diesen Schritt auch ausführen, indem er eine Anforderung als Eingang in ein Transaktionsverarbeitungssystem (110) eingibt, um dieses Transaktionsverarbeitungssystem dazu zu bringen, die Sub-Transaktion (106) zu beenden.

Das bevorzugte Ausführungsbeispiel hat also den Vorteil, dass eine erweiterte Transaktion, die eine Benutzertransaktion und verschachtelte Sub-Transaktionen umfasst, flexibel koordiniert werden kann, indem der Transaktionskoordinator in Zusammenarbeit mit dem Terminator-Prozessor verwendet wird. Obwohl der Terminator-Prozessor als getrennte Komponente bezeichnet wurde und auch hier so behandelt wird, dürfte für einen Fachmann klar erkennbar sein, dass der Terminator- Prozessor in Wirklichkeit Teil des Transaktionskoordinatormoduls oder eines anderen Moduls des Transaktionsverarbeitungssystems sein kann.

Ein Beispiel für eine Situation, in der das bevorzugte Ausführungsbeispiel vorteilhaft ist, wäre eine Situation, in der zwei verschachtelte Sub-Transaktionen gestartet werden, um zwei echte alternative Geschäftsvorgänge in der erweiterten Transaktion durchzuführen, in denen beispielsweise, wie oben beschrieben, zwei alternative Mietwagenbuchungen durchgeführt werden, von denen jedoch nur eine wirklich erforderlich ist. Damit die erweiterte Transaktion erfolgreich ist, muss nur eine der verschachtelten Sub-Transaktionen erfolgreich sein. In dem bevorzugten Ausführungsbeispiel wird der Transaktionskoordinator also so vorbereitet, dass er ein Gesamtergebnis für die erweiterte Transaktion koordiniert, sobald er Eingänge für die Benutzertransaktionen und eine erste der beiden verschachtelten Sub-Transaktionen empfängt und verarbeitet.

Die zweite verschachtelte Sub-Transaktion darf jetzt nicht mehr normal zu Ende geführt werden und mögliche Aktualisierungen durchführen, noch darf sie die normale Fehlerbearbeitung durchlaufen. Der Transaktionskoordinator (112) und der Terminator-Prozessor (116) des bevorzugten Ausführungsbeispiels werden also über das Programm darauf vorbereitetet, anhand der verfügbaren Ergebnisdaten und der Mindest-"Erfolgs"-Voraussetzung für die jeweilige erweiterte Transaktion ein Ergebnis zu erzeugen und vor der Abschlussverarbeitung jede verschachtelte Sub-Transaktion zu beenden, deren Abschluss nicht erforderlich ist, damit die erweiterte Transaktion die Mindest-"Erfolgs"-Voraussetzung erfüllt (oder deren Abschluss - sei es auf normalem oder auf nicht normalem Wege - nicht erwünscht ist). Der Begriff "Erfolg" bedeutet hier ausschließlich "Erfüllen einer bestimmten Reihe von Kriterien". Die Reihe von Kriterien für jede erweiterte Transaktion ist flexibel programmierbar, um die Anforderungen der erweiterten Transaktion zu erfüllen. Bei einigen Transaktionsverarbeitungssystemen zur Verarbeitung erweiterter Transaktionen kann daher eine bestimmte fehlgeschlagene Transaktion, bei der dieses Fehlschlagen jedoch sauber vonstatten ging (das heißt, ohne einen Verlust der Datenintegrität zu verursachen) unter bestimmten Voraussetzungen als "Erfolg" im Sinne der Ergebnisverarbeitung gewertet werden, wie sie hier beschrieben wird.

Fig. 2 ist ein Flussbild, das die Schritte einer Methode entsprechend einem bevorzugten Ausführungsbeispiel zeigt. In Schritt (210) empfängt der Transaktionskoordinator einen Eingang von einer Benutzertransaktion. In Schritt (220) empfängt der Transaktionskoordinator einen Eingang von einer Sub-Transaktion. In Schritt (230) ermittelt der Transaktionskoordinator ein Ergebnis für die erweiterte Transaktion. In Schritt (240) entscheidet der Transaktionskoordinator, aufgrund einiger Kriterien, die für die erweiterte Transaktion festgelegt und flexibel in dem System programmiert wurden, dass eine weitere Sub-Transaktion beendet werden soll. In Schritt (250) bewirkt der Transaktionskoordinator die Beendigung der weiteren Sub- Transaktion.

In Fig. 3 läuft in einem Transaktionsverarbeitungssystem (300) eine erweiterte Transaktion (301), umfassend eine Benutzertransaktion (302) und ihre beiden verschachtelten Sub-Transaktionen (303, 310). Die Benutzertransaktion (302) liefert einen Eingang (304), der dem Transaktionskoordinator (313) ein Ergebnis anzeigt (beispielsweise "Request_Commit" oder "Request Rollback"). Die Sub-Transaktion (303) liefert ebenfalls einen Eingang (305), der dem Transaktionskoordinator (313) ein Ergebnis anzeigt (beispielsweise wieder "Request Commit" oder "Request Rollback"). In dem vorliegenden Beispiel setzt die Sub-Transaktion (310) die Verarbeitung ohne Erzeugen eines Ergebnisses fort.

Der Transaktionskoordinator (313) akzeptiert die Eingänge (304, 305) und verarbeitet sie, um ein koordiniertes Ergebnis zu produzieren. Innerhalb des Transaktionskoordinators (313) bildet der Ergebnis-Mapper (306) die Eingänge (304, 305) in eine verwendbare Form ab, so dass sie von dem Ergebnisprozessor (308) verarbeitet werden können. Der Ergebnis-Mapper (306) stellt dem Ergebnisprozessor (308) abgebildete Eingänge (307) zur Verfügung. Der Ergebnisprozessor (308) verarbeitet den Eingang (307) entsprechend einem vorbestimmten Prozess und überträgt das verarbeitete Ergebnis (309), so dass es von dem Transaktionsverarbeitungssystem (300) verarbeitet werden kann.

In dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung wird das Ergebnis (309) auch als Eingang in einen Terminator-Prozessor (311) akzeptiert, der die Sub- Transaktion (310) beendet, bevor sie bis zum Abschluss weiterverarbeitet wird. Der Terminator-Prozessor (311) kann diese Aufgabe entsprechend Fig. 3 ausführen, indem er einen Befehl "beenden" als spezifischen Eingang (312) an die Sub- Transaktion (310) ausgibt. Alternativ kann diese Aufgabe auch ausgeführt werden, indem eine Anforderung als Eingang in das Transaktionsverarbeitungssystem geschickt wird, damit das Transaktionsverarbeitungssystem (100) die Sub-Transaktion (106) beendet.

In dem Ergebnis-Mapper (306) wird jeder der Eingänge (304, 305) entsprechend einer vorbestimmten Abbildung abgebildet. Die Eingänge können beispielsweise auf ein Zweiwert-System abgebildet werden, das die Ergebnisse entweder als "wahr" oder "falsch" erkennt. Die Ergebnisse können dann anschließend mit Hilfe der Booleschen Logik manipuliert werden. Es ist jedoch nicht unbedingt Voraussetzung, dass ein zweiwertiges System verwendet wird. In vielen Transaktionsumgebungen ist es nämlich erforderlich, drei Eingangswerte von Sub-Transaktionen zu unterscheiden, Request_commit, Request_rollback und Readonly. "Readonly" wird von einer Sub-Transaktion verwendet, um anzuzeigen, dass von ihr keine Ressourcen aktualisiert wurden und die Transaktion daher nicht berücksichtigt werden muss, wenn festgestellt werden soll, ob Ressourcenaktualisierungen, die von den anderen teilnehmenden Komponenten durchgeführt wurden, wie ein Commit oder ein Rollback behandelt werden sollen.

Alternativ kann der Ergebnis-Mapper (306) beispielsweise Eingänge von "Request_commit" und "Request_rollback" oder "wahr" und "falsch" in numerische Werte abbilden, die anschließend von dem Ergebnisprozessor (308) akkumuliert und als Ergebnis (309) mit einer numerischen Zählung übertragen werden können. Hiermit wäre es möglich, ein Mehrheits- Ergebnisentscheidungssystem einzusetzen, bei dem ein bestimmter Schwellenwert von Teilnehmereingängen überschritten werden muss.

In einem herkömmlichen Transaktionssystem würde die Kombination "Request_commit" und "Request_rollback" typischerweise als eine unvermeidliche "Rollback"- Entscheidung verarbeitet. Wie aus Fig. 3 deutlich wird, ist dies bei dem bevorzugten Ausführungsbeispiel nicht der Fall. Hier kann der Ergebnis-Mapper (306) mit einem sehr flexiblen Satz von Abbildungsregeln ausgestattet sein, um Eingänge in einer Vielfalt unterschiedlicher Formen zu akzeptieren, und diese auf ein System mit einer Reihe vergleichbarer Formen abzubilden. Außerdem kann der Ergebnisprozessor (308) hier mit einer flexiblen Gruppe von Verarbeitungsregeln ausgestattet sein, um die ihm zugeführten abgebildeten Werte zu verarbeiten. In einem einfachen Beispiel kann der Ergebnisprozessor (308) eines Systems, in dem nur eine der Sub-Transaktionen (303, 310) erfolgreich sein muss, angewiesen werden, auf die dem Eingang (307) zugeführten Werte ein Boolesches logisches XOR (Exklusiv-Oder) anzuwenden. Weil das Ergebnis von "wahr XOR falsch" "wahr" ist, wäre in diesem Fall das Ergebnis (309) "wahr", womit richtig angezeigt wird, dass nur eine der Komponenten (303, 310) erfolgreich war.

Das bevorzugte Ausführungsbeispiel kann vorteilhaft in einer Enterprise Java Bean Umgebung genutzt werden, in der die Fähigkeit, komplexe Interaktionen zwischen Gruppen von Verarbeitungskomponenten in Relation zu heterogenen Ressourcen und mit dem erforderlichen Grad an Robustheit zu steuern, immer wichtiger wird.

Das bevorzugte Ausführungsbeispiel wurde hier der Einfachheit halber in seiner einfachsten Form beschrieben, nämlich einer Form, in der die Benutzertransaktion der erweiterten Transaktion nur zwei verschachtelte Sub-Transaktionen hat. Wie für den Fachmann klar sein dürfte, gibt es in Wirklichkeit in der erweiterten Transaktionsumgebung typischerweise viele verschachtelte Sub-Transaktionen, die koordiniert werden müssen.

Claims

1. Vorrichtung zur Koordination einer erweiterten Transaktion, die mindestens eine Sub-Transaktion aufweist, wobei die genannte Vorrichtung folgendes umfasst:
Mittel zum Empfangen eines Eingangs, der ein Ergebnis einer Benutzertransaktion anzeigt;
Mittel zum Empfangen eines Eingangs, der ein Ergebnis mindestens einer Sub-Transaktion anzeigt;
ansprechend auf die genannten Eingänge, Mittel, um ein Ergebnis für die genannte erweiterte Transaktion zu ermitteln; und
ansprechend auf das genannte Ergebnis, Mittel für die programmierbare Auswahl der Beendigung einer oder mehrerer Sub-Transaktionen vor der Abschlussverarbeitung der genannten Sub-Transaktionen;
wodurch die genannte erweiterte Transaktion wählbar bis zum Abschluss geführt werden kann, ohne dass alle Sub- Transaktionen abgeschlossen werden.

2. Vorrichtung nach Anspruch 1, weiter dadurch gekennzeichnet, dass die genannten Eingänge, welche die Ergebnisse anzeigen, Indikatoren für Erfolg oder Nichterfolg der genannten ein oder mehreren Sub- Transaktionen enthalten.

3. Vorrichtung nach Anspruch 1, weiter dadurch gekennzeichnet, dass die genannten Eingänge folgendes umfassen:
Commit-Anforderungen; und
Rollback-Anforderungen.

4. Vorrichtung nach Anspruch 1, weiter dadurch gekennzeichnet, dass die genannten Mittel zur Ermittlung eines Ergebnisses über Programme änderbare Abbildungsmittel umfassen.

5. Vorrichtung nach Anspruch 1, weiter dadurch gekennzeichnet, dass die genannten Mittel zur Ermittlung eines Ergebnisses eine Abbildungstabelle umfassen.

6. Vorrichtung nach Anspruch 1, weiter dadurch gekennzeichnet, dass die genannten Mittel zur Ermittlung eines Ergebnisses ein über Programme änderbares Ergebnisprozessormittel umfassen.

7. Eine Methode zur Koordinierung einer erweiterten Transaktion, die mindestens eine Sub-Transaktion umfasst, wobei die genannte Methode folgende Schritte umfasst:
Empfangen eines Eingangs, der ein Ergebnis einer Benutzertransaktion anzeigt;
Empfangen eines Eingangs, der ein Ergebnis mindestens einer Sub-Transaktion anzeigt;
ansprechend auf die genannten Eingänge, Ermitteln eines Ergebnisses für die genannte erweiterte Transaktion;
ansprechend auf den genannten Schritt des Ermittelns eines Ergebnisses, programmierbares Auswählen, ob eine oder mehrere Sub-Transaktionen vor der Abschlussverarbeitung der genannten Sub-Transaktion beendet werden sollen; und
Beenden der genannten einen oder mehreren Sub- Transaktionen;
wodurch die genannte erweiterte Transaktion wählbar bis zum Abschluss geführt werden kann, ohne dass alle Sub- Transaktionen abgeschlossen werden müssen.

8. Ein Computerprogrammprodukt zur Koordination einer oder mehrerer erweiterter Transaktionen, wobei das genannte Computerprogrammprodukt Computerprogrammbefehle umfasst, die auf einem computerlesbaren Speichermedium gespeichert sind um, wenn sie in einen Computer geladen und ausgeführt werden, einen Computer zu veranlassen, die Schritte einer Methode nach Anspruch 5 auszuführen.