DE60003339T2

DE60003339T2 - Bewahrung der übereinstimmung von passiv-replizierten nicht-deterministischen objekten

Info

Publication number: DE60003339T2
Application number: DE60003339T
Authority: DE
Inventors: Pascal Felber; Gary Hallmark
Original assignee: Oracle International Corp
Current assignee: Oracle International Corp
Priority date: 2000-01-06
Filing date: 2000-12-21
Publication date: 2004-04-29
Anticipated expiration: 2020-12-22
Also published as: EP1247182A1; WO2001050264A1; HK1046455B; US6574750B1; AU2291701A; CA2395282A1; AU771514B2; ATE242896T1; CA2395282C; EP1247182B1; DE60003339D1; HK1046455A1

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf Replikation und insbesondere auf Techniken zum Bewahren der Konsistenz von passiv-replizierten nicht-deterministischen Objekten.
HINTERGRUND DER ERFINDUNG
Es ist eine kritische Eigenschaft geworden, dass elektronische Systeme, auf welche sich die Gesellschaft verlässt, erreichbar und konsistent bleiben. Bezüglich der Erreichbarkeit, kann ein einziger Fall von Unerreichbarkeit ein Unternehmen, welches sich auf den elektronischen Verkehr verlässt, behindern oder gar lahm legen. Bezüglich der Konsistenz gibt es eine bestimmte Klasse von Operationen, die nur dann durchgeführt werden sollten, wenn andere Operationen auch durchgeführt werden. Zum Beispiel sollte beim Transfer von Geldern zwischen Bankkonten das eine Konto nur dann mit dem transferierten Betrag belastet werden, wenn auch eine Gutschrift des Betrages auf dem anderen Konto erscheint.
Die Definition der Konsistenz muss im Zusammenhang mit hochverfügbaren, auftragskritischen Anwendungen verfeinert werden. Online-Shopping zum Beispiel beinhaltet kritische Interaktionen zwischen Clients und der geschäftlichen Anwendung am elektronischen Handelsplatz. Unglücklicherweise hat ein Client im Allgemeinen keine Möglichkeit, zu wissen, ob seine Anforderung verarbeitet worden ist oder nicht, wenn während der Verarbeitung seiner Anforderung ein Fehler auftritt (wie etwa ein Fehler des Client, des Netzwerks oder des Server).
Anwendungsserver stellen im Allgemeinen eine sog. "höchstens-Einmal-Semantik" (at-most-once semantic) zur Verfügung, die garantiert, dass, wenn eine Anforderung verarbeitet worden ist, diese nur einmal verarbeitet worden ist. Diese Qualität des Dienstes ist nicht ausreichend, da sie die Verantwortung für die Entscheidung, ob eine Anforderung neu ausgeführt werden muss oder nicht, dem Client überlässt.
Die Qualität des Dienstes, die bei auftragskritischen verteilten Anwendungen benötigt wird ist "exakt-einmal" (exactly-once). Im Idealfall will der Client die Garantie, dass seine Anforderung bei Gelegenheit verarbeitet wird und dass die Verarbeitung nur einmal erfolgt. Diese Problemstellung ist als End-zu-End-Zuverlässigkeit (end-to-end-reliability) bekannt. Die "Alles-oder-Nichts"-Eigenschaft, die für die Konsistenz der Anwendung notwendig ist, sollte Idealerweise "alles" werden.
Die End-zu-End-Zuverlässigkeit kann definiert werden als die Garantie, dass eine Anforderung, die von einem Client an einen Server gesendet wird, bei Gelegenheit verarbeitet wird, und dass der Client eine Antwort erhält, und zwar unabhängig davon, ob in einer Serverkomponente des Systems ein Fehler auftritt. Die Anforderung wird vom Server genau einmal verarbeitet. Außerdem kann der Client, wenn der Fehler beim Client liegt, noch immer eine Antwort nach dem Wiederherstellen der Funktion erhalten.
Ein typisches Szenario ist das eines Endnutzers, welcher Flugtickets über einen elektronischen Handelsplatz kauft. Wenn im Handelsplatz ein Fehler auftritt, bevor der Nutzer den Handelsplatz verlässt, dann muss der Nutzer seine Auswahl erneut vornehmen, er erhält jedoch keine Rechnung für das, was er vor dem Fehler ausgewählt hat. Wenn jedoch ein Fehler auftritt, nachdem ein Nutzer seinen Kauf bestätigt hat, aber bevor er die Bestätigung empfangen hat, dann kann er üblicherweise nicht wissen, ob die Anforderung verarbeitet worden ist oder nicht; der Handelsplatz muss Protokollmechanismen zur Verfügung stellen, auf die der Endnutzer einfach zurückgreifen kann.
In diesem Szenario bedeutet die End-zu-End-Zuverlässigkeit, dass der Nutzer die Garantie hat, dass seine Anforderung schließlich verarbeitet wird, nachdem sie getätigt worden ist, wenn die Client-Anwendung (z.B. ein Internetbrowser) nicht fehlerhaft arbeitet. Wenn der Client fehlerhaft arbeitet, dann kann die Anforderung bei Wieder herstellen der Funktion des Client mit der Garantie neu ausgegeben werden, dass sie nicht zweimal verarbeitet werden wird.
Dieses Szenario kann dahingehend ausgedehnt werden, dass es verschachtelte Anforderungen einschließt. Zum Beispiel können Endnutzer ihre Ferien über eine Internetseite planen, die den Erhalt von Flugtickets, das Mieten von Autos und das Reservieren von Hotels vermittelt. Dieses Beispiel illustriert die Verwendung von verschachtelten Anforderungen zwischen Anwendungsservern: Die Ferien-Internetseite fungiert als Client für andere Seiten zum Buchen von Flugtickets, Mietautos und Hotelzimmern.
Dieses Szenario weist Probleme auf, die mit dem Ausführen einzelner Anforderungen auftreten können. Angenommen, ein Endnutzer will nach London reisen. Wenn ein Server zum Planen von Ferien ein Auto und ein Hotelzimmer in London bucht, aber ein Fehler auftritt, bevor er das Flugticket erhält, sind die beiden ersten Reservierungen bedeutungslos. In diesem Zusammenhang sei angemerkt, dass die End-zu-End-Zuverlässigkeit nicht bedeutet, dass alle drei Reservierungen erfolgreich sein werden. Sie bedeutet vielmehr, dass die Anforderung des Clients vollständig verarbeitet werden wird. Die Internetseite zum Planen der Ferien kann z.B. die Reservierung des Mietautos und des Hotels widerrufen, wenn alle Flugzeuge nach London voll sind.
Replikation ist eine Technik, die weitverbreitet verwendet wird, um die Erreichbarkeit von Systemen zu erhöhen. Im Allgemeinen beinhaltet die Replikation das Aufrechterhalten von Kopien ("Replikas") von Ressourcen, so dass ein anderes Exemplar des replizierten Objektes Verwendung finden kann, wenn ein Exemplar fehlerhaft ist. Zum Beispiel kann ein Client Zugang zu einer speziellen Tabelle einer Datenbank benötigen. Um die Verfügbarkeit zu erhöhen, können Kopien der Tabelle von vielen verschiedenen Datenbankservern gehandhabt werden. Wenn eine der Kopien der Tabelle beschädigt wird oder wenn einer der Datenbankserver fehlerhaft arbeitet, können alle Clients, die auf die nicht länger verfügbare Kopie der Tabelle zugegriffen haben, mit dem Zugriff auf die Tabelle fortfahren, indem sie eine andere Kopie davon verwenden.
Das replizierte Objekt wird von einem Kopiensatz dargestellt. Dieser Satz kann entweder statisch oder dynamisch sein. Die statische Replikation setzt voraus, dass sich die Zahl und die Identität der Kopien während der Lebensdauer des replizierten Objektes nicht verändert, wohingegen die dynamische Replikation es erlaubt, Kopien während des Betriebes hinzuzufügen oder zu entfernen.
In verteilten Systemen sind die beiden am besten bekannten Replikationsstrategien die aktive Replikation und die passive Replikation (auch Primär-Backup-Replikation genannt). In der aktiven Replikation spielen alle Kopien des replizierten Objektes dieselbe Rolle. Wenn ein Client eine Anforderung an ein aktiv repliziertes Objekt sendet, empfangen alle Exemplare des Objekts jede Anforderung, verarbeiten die Anforderung, aktualisieren auf die Anforderung hin ihren Status und senden eine Antwort zurück an den Client. Weil die Anforderungen immer an alle Exemplare des replizierten Objektes gesendet werden, ist eine Fehlfunktion eines der Exemplare für den Client transparent.
Bei der passiven Replikation wird ein Exemplar als primäres Exemplar ausgewählt, während alle anderen Exemplare Backups (Sicherungskopien) sind. Clients führen Anforderungen durch, indem sie Botschaften nur zum primären Exemplar senden, welches die Anforderung ausführt, die anderen Exemplare aktualisiert und die Antwort zum Client sendet. Wenn das primäre Exemplar fehlerhaft arbeitet, dann übernimmt eines der Backup-Exemplare die Stelle des primären Exemplars.
Das Hauptproblem bei der Replikation ist, dass konventionelle Replikationstechniken voraussetzen, dass die replizierten Objekte deterministisch sind. Ein Objekt wird als deterministisch bezeichnet, wenn das Ergebnis einer an das Objekt gestellten Anforderung (eines Aufrufs des Objektes) nur vom Zustand des Objektes vor dem Aufruf und von den Parametern des Aufrufs abhängt. Somit behalten zwei deterministische Objekte mit identischen Zuständen ihre identischen Zustände, wenn sie beide denselben Satz von Anforderungen in derselben Reihenfolge erhalten.
Die Integrität eines Systems kann beschädigt werden, wenn replizierte Objekte nicht deterministisch sind. Zum Beispiel kann es passieren, dass, wenn in einem aktiven Replikationssystem zwei Exemplare basierend auf derselben Eingabe zu zwei verschiedenen Zuständen gelangen, das Umschalten zwischen den Exemplaren zu einem unvorhersehbaren Verhalten führt. In passiven Replikationssystemen ist das von nicht-deterministischen Objekten verursachte Problem weniger offensichtlich, jedoch genauso schädlich, insbesondere wenn die nicht-deterministischen Objekte mit anderen Einheiten interagieren.
1 stellt ein Szenario dar, in welchem ein Client C ein einzelnes repliziertes Objekt X aufruft, welches wiederum ein anderes repliziertes Objekt Y aufruft und dann ein nicht-repliziertes Objekt Z. Der Satz von verschachtelten Aufrufen bildet einen sogenannten "Aufrufbaum". In diesem Szenario weiß Y von der Replikation, da es selber repliziert ist, wohingegen Z von der Replikation überhaupt nichts zu wissen braucht. In Folge dessen kann angenommen werden, dass nur Y Mechanismen zum Behandeln von replizierten Aufrufen realisiert.
Das Hauptproblem beim Handhaben von replizierten Objekten ist es, die Konsistenz des replizierten Zustandes aufrecht zu erhalten, d.h. sicherzustellen, dass alle Exemplare einen gemeinsamen Zustand aufweisen. Die Konsistenz muss auf allen Ebenen des Aufrufbaums erhalten bleiben. Zum Beispiel ist es in 1 nicht akzeptabel, dass Y eine Anforderung empfängt und verarbeitet, während Z dies aufgrund einer Fehlfunktion von X nicht tut. Der Replikationsmechanismus muss sicherstellen, dass entweder alle Objekte im Aufrufbaum ihre Anforderung verarbeiten oder dass keines der Objekte dies tut. Diese Alles oder Nichts-Eigenschaft ähnelt der Untrennbarkeits-Eigenschaft (atomicity property) eines Transaktionssystems (transactional system).
Eine Vorgehensweise zum Garantieren der Atomizität von Aufrufen in Szenarien wie dem in 1 dargestellten wird als Vorwärtsroll-Vorgehensweise (roll-forward approach) bezeichnet. Die Vorwärtsroll-Vorgehensweise benutzt Redundanz, um sicherzustellen, dass ein anderes Exemplar den Vorgang bei einer Fehlfunktion des Hauptexemplars in transparenter Weise übernimmt, ohne dabei Informationen zu verlieren. Die Konsistenz wird dadurch aufrecht erhalten, dass garantiert wird, dass der Aufruf trotz des Fehlers erfolgreich sein wird (durch "Vorwärtsrollen"). Passive Replikationstechniken, welche eine Vorwärtsroll-Vorgehensweise verwenden, stellen sicher, dass nur das primäre Exemplar die Anforderung verarbeitet. Zu den Backup-Exemplaren werden Aktualisierungen gesendet. Wenn das primäre Exemplar eine Fehlfunktion während des Verarbeitens einer Anforderung hat, wird ein Backup-Exemplar als neues primäres Exemplar ausgewählt. Die Anforderung, während deren Bearbeitung der Fehler aufgetreten ist, wird dann an das neue primäre Exemplar gesendet, welches das Verarbeiten des Vorganges an diesem Punkt fortsetzt.
Es wird allgemein angenommen, dass eine passive Replikationstechnik mit einer Vorwärtsvoll-Vorgehensweise ausreicht, um nicht-deterministische Server zu unterstützen. Diese Techniken sind jedoch nur im fehlerfreien Fall ausreichend, weil ein nicht-deterministisches Objekt mit anderen Objekten, deren Identität von nichtdeterministischen Faktoren abhängt, interagieren kann. Zum Beispiel kann X in 1 Y aufrufen, falls eine Bedingung erfüllt ist (z.B. ein Zeitgeber noch nicht abgelaufen ist), und anderenfalls Z. In dieser Situation kann X abstürzen, nachdem es Y aufgerufen hat, aber bevor die Backups aktualisiert worden sind. Das Backup, welches den Aufruf übernimmt und verarbeitet, könnte Z statt Y aufrufen und das System in einem inkonsistenten Zustand zurücklassen.
Unglücklicherweise kann in vielen realen Situationen und Systemen ein deterministisches Verhalten nicht garantiert werden. Daher besteht einen Bedarf an einem System und einer Technik, mit der sich die Vorteile einer Objektreplikation zur Verfügung stellen lassen, während die Genauigkeit von Ergebnissen in einer Umgebung, in der nicht garantiert werden kann, das replizierte Objekte deterministisch sind, aufrechterhalten werden kann.
Frank et al. in "Semantic ACID Properties in Multidatabases Using Remote Procedure Calls and Update Propagations", Software – Practice and Experience, GB, John Wiley and Sons Ltd., Chichester, Vol. 28, No. 1, 1998, Seiten 77 bis 98, offenbaren ein Verfahren zum zur Verfügungsstellen von Transaktionen in Datenbanken mit den Eigenschaften einer globalen ACID-Semantik (atomicity, consistency, isolation and durability- Untrennbarkeit, Konsistenz, Entkopplung und Dauerhaftigkeit) in einer Client-Server-Architektur.
US-A-5864854 offenbart ein Verfahren zum Zwischenspeichern von Dateneinheiten für eine Gruppen von Clients unter Verwendung einer Nachschlagetabelle für einen Gruppen-Zwischenspeicher, die für jedes von einem beliebigen Mitglied der Gruppe zwischengespeicherte Datenelement einen Eintrag sowie eine Liste mit Client-Bezeichnern für jeden die Datenelemente zwischenspeichernden Client enthält.
ZUSAMMENFASSUNG DER ERFINDUNG
Die Erfindung, wie sie durch die Ansprüche definiert ist, stellt Techniken zum Ausführen einer Operation, in welcher ein Client ein repliziertes Objekt aufruft, zur Verfügung. Gemäß einer Technik empfängt ein primäres Exemplar des replizierten Objektes eine erste Anforderung vom Client, wobei die erste Anforderung einen Anforderungsbezeichner enthält. Anstatt sofort zu versuchen, die Anforderung zu verarbeiten, ermittelt das primäre Exemplar, ob eine Aufzeichnung existiert, welche dem Anforderungsbezeichner entspricht. Wenn eine Aufzeichnung existiert, die dem Anforderungsbezeichner entspricht, dann antwortet das primäre Exemplar auf die erste Anforderung mit einer Antwort, die mit der Aufzeichnung in Beziehung steht. Wenn keine der Anforderung entsprechende Aufzeichnung existiert, dann führt das primäre Exemplar die folgenden Schritte aus: Starten der Transaktion; Bearbeiten der Anforderung als Teil der Transaktion; Speichern einer Aufzeichnung, die dem Anforderungsbezeichner zugeordnet ist, und einer Antwort auf die Anforderung als Teil der Transaktion; Bestätigen der Transaktion; und Übermitteln einer Antwort an den Client.
Der Client kann selber ein repliziertes Objekt sein. Wenn der Client nicht-deterministisch ist, dann kann die Transaktion, die vom primären Exemplar ausgelöst wird, bezüglich der Transaktion, welche vom Client ausgeführt wird, eine verschachtelte Transaktion sein oder kann als Teil derselben Transaktion wie der Client ausgeführt werden. Wenn die vom primären Exemplar ausgeführte Transaktion als Teil der selben Transaktion wie die des Client ausgeführt wird, dann kann ein Sicherungs punkt (savepoint) etabliert werden, bevor das primäre Exemplar die Anforderung verarbeitet, so dass eine Fehlfunktion nicht notwendigerweise erfordert, dass die gesamte vom Client ausgeführte Verarbeitung rückabgewickelt werden muss.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung ist in den Figuren der beiliegenden Zeichnungen beispielhaft und nicht einschränkend dargestellt, wobei sich gleiche Bezugszeichen auf ähnliche Elemente beziehen.
1 ist ein Blockdiagramm eines Systems, in welchem ein Client ein repliziertes Objekt aufruft, welches wiederum zwei andere Objekte aufruft;
2A ist ein Flussdiagramm für Schritte, die von einem Client gemäß einer Ausführungsform der Erfindung ausgeführt werden;
2B ist ein Flussdiagramm für Schritte, die vom primären Exemplar eines replizierten Objektes gemäß einer Ausführungsform der Erfindung ausgeführt werden;
3 ist ein Blockdiagramm, welches ein nicht-fehlerbehaftetes Szenario gemäß einer Ausführungsform der Erfindung darstellt;
4 ist ein Blockdiagramm, welches ein Szenario gemäß einer Ausführungsform der Erfindung darstellt, in dem ein Objekt, welches mit einem verschachtelten Aufruf aufgerufen worden ist, nach dem Auslösen einer Transaktion eine Fehlfunktion aufweist;
5 ist ein Blockdiagramm, das ein Szenario gemäß einer Ausführungsform der Erfindung darstellt, in dem ein Objekt, welches mit einem verschachtelten Aufruf aufgerufen worden ist, nach dem Bestätigen einer Transaktion eine Fehlfunktion aufweist;
6 ist ein Blockdiagramm, welches ein Szenario gemäß einer Ausführungsform der Erfindung darstellt, in dem ein Objekt einen verschachtelten Aufruf ausführt und eine Fehlfunktion aufweist, nachdem das in der verschachtelten Transaktion aufgerufene Objekt die Transaktion bestätigt;
7 ist ein Blockdiagramm, welches ein Szenario gemäß einer Ausführungsform der Erfindung darstellt, in dem ein Objekt einen verschachtelten Aufruf ausführt und eine Fehlfunktion aufweist, nachdem das in der verschachtelten Transaktion aufgerufene Objekt die Transaktion bestätigt; und
8 ist ein Blockdiagramm eines Computersystems gemäß einer Ausführungsform der Erfindung, auf dem die Ausführungsformen der Erfindung realisiert werden können.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
Ein Verfahren und eine Vorrichtung zum Ausführen einer Operation, in welcher ein Client ein repliziertes Objekt aufruft, wird beschrieben. In der nachfolgenden Beschreibung werden zum Zwecke der Erläuterung zahlreiche spezifische Details erklärt, um ein tiefgehendes Verständnis der vorliegenden Erfindung zu erzielen. Ein Fachmann erkennt jedoch, dass die vorliegende Erfindung ohne diese spezifische Details ausgeführt werden kann. Bei anderen Beispielen werden wohlbekannte Strukturen und Vorrichtungen in Form von Blockdiagrammen gezeigt, um die Erfindung nicht unnötigerweise zu verschleiern.
FUNKTIONSÜBERBLICK
Es werden Techniken zur Verfügung gestellt, um eine passive Replikation unter Verwendung einer Rückabwicklungs-Vorgehensweise ("roll-backwards" approach) durchzuführen, welche kein deterministisches Verhalten der replizierten Objekte erfordert. Die Techniken können z.B. im Zusammenhang mit verteilter Middleware eingesetzt werden, um eine transparente Replikation und eine transparente Übergabe beim Vorliegen einer Fehlfunktion zur Verfügung zu stellen. Die Technik basiert auf Transaktionen und hat andere Eigenschaften als herkömmliche Vorgehensweisen, die auf Gruppenkommunikation und roll-forward-Techniken basieren.
TRANSAKTIONEN
Eine Transaktion ist eine Folge von Operationen an Objekten oder Datenelementen, welche die folgenden vier Eigenschaften erfüllt (ACID-Eigenschaften):
Untrennbarkeit (atomicity): Entweder werden alle Operationen der Transaktion ausgeführt, oder keine davon wird ausgeführt.
Konsistenz (consistency): Eine Transaktion muss dahingehend korrekt sein, dass sie Daten von einem konsistenten Zustand zu einem anderen transformiert.
Entkopplung (isolation): Wenn mehrere Transaktionen gleichzeitig ausgeführt werden, muss jede von ihnen so erscheinen, als ob sie alleine ausgeführt würde.
Dauerhaftigkeit (durability): Trotz Zusammenbrüchen (crashes) ist die Wirkung durchgeführter Operationen dauerhaft.
Wenn ein Fehler im System auftritt oder die Transaktion aus irgendeinem Grund nicht bestätigt (committed) werden kann, wird sie rückabgewickelt (rolled back), d.h. alle Modifikationen, die bis zu diesem Punkt durchgeführt worden sind, werden rückgängig gemacht, und das System kehrt in seinen vorherigen Zustand zurück. Einige Systeme unterstützen verschachtelte Transaktionen, in denen Transaktionen im Rahmen anderer Transaktionen gestartet werden können. Wenn die verschachtelte Transaktion fehlschlägt, wird die einschließende Transaktion nicht automatisch rückabgewickelt, und die Anwendung kann versuchen, das Problem zu korrigieren und einen neuen Versuch, die Transaktion durchzuführen, starten. Wenn die einschließende Transaktion rückabgewickelt wird, dann werden auch alle verschachtelten Transaktionen rückabgewickelt.
PASSIVE REPLIKATION, DIE AUF EINER TRANSAKTION BASIERT
Es werden Techniken zum Durchführen von passiven Replikationen, welche auf einer Transaktion basieren, in einer Weise zur Verfügung gestellt, die genaue Ergebnisse liefert, selbst wenn ein Fehler in einem nicht-deterministischen replizierten Objekt auftritt. Zum Zwecke der Darstellung sollen diese Techniken mit Bezug auf ein System beschrieben werden, welches einen Aufrufbaum einschließt, der drei Einheiten beinhaltet. Die erste Einheit im Aufrufbaum soll als der Client oder "C" bezeichnet werden. Die zweite Einheit im Aufrufbaum (die Einheit, die vom Client aufgerufen wird) soll als Objekt X oder "X" bezeichnet werden. Die dritte Einheit im Aufrufbaum (die Einheit, die von X aufgerufen wird) soll als Objekt Y oder "Y" bezeichnet werden.
Es soll erwähnt werden, dass diesen Einheiten die Bezeichnungen lediglich zum Zwecke der Erklärung gegeben worden sind und die Art der involvierten Einheiten in keiner Weise einschränken. Außerdem sind die Techniken in keiner Weise auf Aufrufbäume, welche drei Einheiten beinhalten, beschränkt. Ein Aufrufbaum mit drei Einheiten ist jedoch ausreichend, um darzustellen, wie alle Einheiten in einem Aufrufbaum relativ zu den Einheiten, durch die sie aufgerufen werden, und zu den Einheiten, welche sie aufrufen, reagieren.
2A ist ein Flussdiagramm, das die Schritte darstellt, welche vom Client C in einem passiven Replikationssystem gemäß einer Ausführungsform der Erfindung, welches auf einer Transaktion basiert, ausgeführt werden. In 2A ruft der Client C in Schritt 202 das primäre Exemplar des Objektes X auf. Das primäre Exemplar X soll hierbei als X1 bezeichnet werden. Nach dem Aufrufen von X1 wartet der Client auf eine Antwort von X1. Wenn X1 nicht innerhalb einer vorbestimmten Zeitperiode (Schritt 204) antwortet, nimmt der Client C an, dass X1 fehlerhaft ist und wählt ein neues primäres Exemplar aus (Schritt 206). Der Client C ruft dann das neue primäre Exemplar auf (Schritt 202). Diese Folge wird solange wiederholt, bis eines der Exemplare des Objektes X innerhalb des spezifizierten Zeitintervalls erfolgreich auf den Aufruf antwortet.
2B ist ein Flussdiagramm, das die Schritte darstellt, welche vom primären Exemplar des Objektes X in einen passiven transaktionsbasierten Replikationssystem gemäß einer Ausführungsform der Erfindung ausgeführt werden. In 2B empfängt das primäre Exemplar des Objektes X (d.h. X1) in Schritt 250 die Anforderung vom Client C. In Schritt 252 stellt X1 fest, ob die empfangene Anforderung mit einer Anforderung, welche bereits vom Objekt X verarbeitet worden ist, identisch ist. Gemäß einer Ausführungsform wird diese Feststellung getroffen, indem (1) ein Anforderungsbezeichner der Anforderung gelesen wird und (2) der Anforderungsbezeichner mit Anforderungsbezeichnern verglichen wird, welche in Aufzeichnungen, die in einem Protokoll gespeichert sind, enthalten sind, wobei das Protokoll Aufzeichnungen von allen Antworten enthält, die durch alle Exemplare des Objektes X übergeben worden sind. Wenn der Anforderungsbezeichner der Anforderung mit einem Anforderungsbezeichner einer Aufzeichnung in dem Protokoll übereinstimmt, dann antwortet X1 auf die Anforderung, indem es die Antwort ausgibt, welche von der Aufzeichnung in dem Protokoll angezeigt wird (Schritt 258).
Wenn der Anforderungsbezeichner in der Anforderung mit keinem Anforderungsbezeichner in einer Aufzeichnung des Protokolls übereinstimmt, dann geht die Steuerung zu Schritt 254 über. In Schritt 254 beginnt X eine Transaktion TX. Nach dem Begin der Transaktion führt X1 als Teil der Transaktion all diejenigen Operationen aus, die für das Bedienen der Anforderung benötigt werden. Zum Zwecke der Darstellung soll angenommen werden, dass eine dieser Operationen das Aufrufen eines weiteren replizierten Objektes Y beinhaltet. Daher sendet X1 in Schritt 256 eine Anforderung an das primäre Exemplar des Objektes Y (Y1). In Schritt 260 empfängt X1 eine Antwort von Y1. In Schritt 262 protokolliert X1 die Antwort von Y1. In Schritt 264 bestätigt X1 die Transaktion, nachdem alle für die Anforderung benötigten Operationen von X1 ausgeführt worden sind. Nach dem Bestätigen der Transaktion sendet X1 die Antwort auf die Anforderung an C (Schritt 266).
Es sollte erwähnt werden, dass X1 relativ zu Y1 ein Client ist. Konsequenterweise führt X1 die in 2A gezeigten Schritte aus, wenn X1 eine Anforderung an Y1 sendet. Insbesondere wartet X1 auf eine Antwort. Wenn die Antwort nicht innerhalb einer vorbestimmten Zeitperiode nach dem Senden der Anforderung an Y1 eintrifft, dann wählt X1 ein anderes Exemplar von Y als primäres Exemplar aus und sendet die Anforderung an das neue primäre Exemplar von Y. Dieser Prozess wird solange wiederholt, bis X1 erfolgreich eine Antwort von einem der Exemplare von Y erhält.
Wie mittels der Szenarien, welche nachfolgend beschrieben sind, dargestellt werden wird, empfangen die Clients in einem System, in welchem Clients und primäre Exemplare so konfiguriert sind, dass sie so arbeiten, wie es in 2A bzw. 2B dargestellt ist, korrekte Antworten, selbst dann, wenn Fehler in nichtdeterministischen replizierten Objekten auftreten.
SZENARIO OHNE FEHLFUNKTION
3 ist ein Blockdiagramm, das eine Reihe von Ereignissen darstellt, wenn kein Fehler in einem Aufrufbaum, welcher drei Einheiten enthält, auftritt, und wobei die Clients und die primären Exemplare so konfiguriert sind, dass sie so arbeiten, wie es in 2A bzw. 2B beschrieben ist. In 3 ruft der Client C das primäre Exemplar von X (X1) auf. Der Aufruf schließt einen Anforderungsbezeichner (rid1) ein. Als Reaktion auf das Empfangen des Aufrufs führt X1 eine Nachschlag-Operation (lookup operation) aus, um festzustellen, ob ein Protokoll eine Aufzeichnung enthält, die mit rid1 in Beziehung steht. Im vorliegenden Beispiel hat C die Anforderung zuvor nicht ausgegeben, so dass das Protokoll keine andere Aufzeichnung enthält, die mit rid1 in Beziehung steht.
Auf die Feststellung hin, dass das Protokoll keine Aufzeichnung für rid1 enthält, beginnt X1 eine Transaktion TX und führt dann die Anforderung als Teil der Transaktion aus. Als Teil des Verarbeitens der Anforderung ruft X1 das primäre Exemplar von Y (Y1) auf. Der Aufruf von Y1 enthält einen Anforderungsbezeichner (rid2). Nach dem Empfangen des Aufrufs führt Y1 eine Nachschlag-Operation aus, um festzustellen, ob ein Protokoll eine Aufzeichnung enthält, welche mit rid2 in Beziehung steht. Im vorliegenden Beispiel hat X1 die Anforderung vorher nicht ausgegeben, so dass das Protokoll keine Aufzeichnung enthält, welche mit rid2 in Beziehung steht.
Auf die Feststellung hin, dass das Protokoll keine Aufzeichnung für rid2 enthält, beginnt Y1 eine Transaktion und führt dann die Anforderung als Teil der Transaktion aus. Gemäß einer Ausführungsform ist die von Y1 begonnene Transaktion mit der von X1 begonnen Transaktion verschachtelt. Als Konsequenz kann die von Y1 begonnene Transaktion rückabgewickelt werden, ohne die gesamte von X1 ausgelöste Transaktion rückabzuwickeln. Außerdem wird die von Y1 begonnene Transaktion automatisch rückabgewickelt, wenn die von X1 ausgelöste Transaktion rückabgewickelt wird.
Zum Zwecke der Darstellung soll angenommen werden, dass Y1 während des Verarbeitens der Anforderung keine weitere Einheit aufruft. Nach dem Verarbeiten der Anforderung protokolliert Y1 eine Aufzeichnung für rid2, welche die Antwort auf die mit rid2 verbundene Anforderung einschließt. Y1 bestätigt dann die verschachtelte Transaktion und sendet die Antwort an X1.
Nach dem Empfang der Antwort von Y1 protokolliert X1 eine Aufzeichnung für rid1, welche die Antwort auf die mit rid1 verbundene Anforderung einschließt. Dann bestätigt X1 die Transaktion und sendet seine Antwort an C. Die verschachtelte Transaktion, welche von Y1 ausgelöst worden ist, wird als Antwort auf das Bestätigen der Transaktion, welche von X1 ausgelöst worden ist, übergeben.
FEHLER VON Y1, BEVOR Y1 BESTÄTIGT
4 ist ein Blockdiagramm, das die Reihenfolge von Ereignissen darstellt, wenn ein spezieller Fehlertyp in einem Aufrufbaum mit drei Einheiten auftritt, wobei die Clients und die primären Exemplare derart konfiguriert sind, dass sie so arbeiten, wie es in 2A bzw. 2B dargestellt ist. Der spezielle in 4 dargestellte Fehler ist die Fehlfunktion von Y1, bevor Y1 seine Transaktion bestätigt. Konsequenterweise ist die Reihenfolge der Ereignisse bis zu dem Punkt, an dem Y1 die Anforderung von X1 verarbeitet, mit dem Szenario ohne Fehler, welches in 3 gezeigt ist, identisch.
Weil Y1 zusammengebrochen ist, empfängt X1 keine Antwort von Y1 innerhalb des vorbestimmten Zeitabschnittes. Weil die Operationen, die von Y1 ausgeführt worden sind, Teil einer verschachtelten Transaktion waren, werden sie rückabgewickelt, ohne die Transaktion, die von X1 gestartet worden ist, rückabzuwickeln. Die Fähigkeit, ohne das Rückabwickeln der Transaktion, die von X1 gestartet worden ist, fortzufahren, kann signifikant sein, beispielsweise wenn X1 bereits vor dem Aufrufen von Y1 einen großen Teil der Transaktion ausgeführt hat.
Als Konsequenz wählt X1 ein neues primäre Exemplar von Y ("Y2") und sendet die Anforderung (die rid2 enthält) an Y2. Auf den Empfang des Aufrufes hin führt Y2 eine Nachschlag-Operation aus, um zu ermitteln, ob ein Protokoll eine Aufzeichnung enthält, die mit rid2 zusammenhängt. Im vorliegenden Beispiel enthält das Protokoll keine Aufzeichnung, die mit rid2 zusammenhängt, weil eine von Y1 erzeugte Protokoll-Aufzeichnung für rid2 nur als Teil einer Transaktion erzeugt worden wäre, die jedoch niemals bestätigt worden ist. Konsequenterweise wäre jede derartige Aufzeichnung beim Rückabwickeln der Transaktion aus dem Protokoll entfernt worden. In ähnlicher Weise werden alle Operationen, die von Y1 vor seiner Fehlfunktion als Antwort auf die Anforderung, die mit rid2 in Beziehung steht, ausgeführt worden sind, rückgängig gemacht.
Auf das Feststellen hin, dass das Protokoll keine Aufzeichnung für rid2 aufweist, beginnt Y2 eine Transaktion und führt dann die Anforderung als Teil der Transaktion aus. Zum Zwecke der Darstellung soll angenommen werden, dass Y2 während des Verarbeitens der Anforderung keine weitere Einheit aufruft. Nach dem Verabreiten der Anforderung protokolliert Y2 eine Aufzeichnung für rid2, welche die Antwort auf die mit rid2 verbundene Anforderung einschließt. Dann bestätigt Y2 die Transaktion und sendet die Antwort an X1.
Nach dem Empfang der Antwort von Y1 protokolliert X1 eine Aufzeichnung für rid1, welche die Antwort auf die mit rid1 verbundene Anforderung beinhaltet. X1 bestätigt dann die Transaktion und sendet seine Antwort an C.
FEHLFUNKTION VON Y1, NACHDEM Y1 BESTÄTIGT HAT
5 ist ein Blockdiagramm, das die Reihenfolge der Ereignisse darstellt, wenn ein spezieller Fehlertyp in einem Aufrufbaum mit drei Einheiten auftritt, wobei der Client und die primären Exemplare derart konfiguriert sind, dass sie so arbeiten, wie es in 2A bzw. 2B dargestellt ist. Der spezielle in 5 dargestellte Fehler ist die Fehlfunktion von Y1, nachdem Y1 seine Transaktion bestätigt hat, aber bevor Y1 eine Antwort an X1 sendet. Konsequenterweise ist die Reihenfolge der Ereignisse bis zu dem Punkt, an dem Y1 auf die Anforderung von X1 antwortet, mit dem in
3 gezeigten Szenario ohne Fehlfunktion identisch.
Weil Y1 vor dem Antworten an X1 zusammengebrochen ist, empfängt X1 keine Antwort von Y1 innerhalb der vorbestimmten Zeitperiode. Als Konsequenz wählt X1 Y2 als neues primäres Exemplar von Y aus und sendet die Anforderung (die rid2 enthält) an Y2. Auf das Empfangen dieses Aufrufes hin führt Y2 eine Nachschlag-Operation aus, um festzustellen, ob ein Protokoll eine Aufzeichnung enthält, die mit rid2 in Beziehung steht. Im vorliegenden Beispiel enthält das Protokoll eine Aufzeichnung, die mit rid2 in Beziehung steht, weil eine mit rid2 in Beziehung stehende Aufzeichnung in einer Transaktion, die bestätigt worden ist, protokolliert worden ist. Die Wirkungen aller Operationen, die von Y1 als Antwort auf die mit rid2 in Beziehung stehende Anforderung durchgeführt worden sind und die vor der Fehlfunktion von Y1 ausgeführt wurden, wurden ebenfalls bestätigt.
Auf das Feststellen hin, dass das Protokoll eine Aufzeichnung für rid2 enthält, liest Y2 die Antwort aus der Aufzeichnung und sendet die Antwort an X1 als Antwort auf die Anforderung von X1. Y2 führt keine weiteren Prozesse als Antwort auf die Anforderung von X1 aus. Nach dem Empfangen der Antwort von Y2 protokolliert X1 eine Aufzeichnung für rid1, welche die Antwort auf die mit rid1 in Beziehung stehende Anforderung enthält. X1 bestätigt dann die Transaktion und sendet seine Antwort an C.
FEHLFUNKTION VON X1 VOR DEM BESTÄTIGEN UND NACH DEM AUFRUFEN Y1, WOBEI X DETERMINISTISCH IST
6 ist ein Blockdiagramm, das die Reihenfolge der Ereignisse darstellt, wenn ein spezieller Fehlertyp in einem Aufrufbaum mit drei Einheiten auftritt, wobei die Clients und die primären Exemplare derart konfiguriert sind, dass sie so arbeiten, wie es in 2A bzw. 2B dargestellt ist. Der spezielle in 6 dargestellte Fehler ist die Fehlfunktion von X1, nach dem Aufrufen von Y1 aber bevor X1 seine Transaktion bestätigt. Konsequenterweise ist die Reihenfolge der Ereignisse bis zu dem Punkt, an dem Y1 seine mit TX verbundene Transaktion bestätigt, dem in 3 gezeigten Szenario ohne Fehlfunktion ähnlich. Anders als in dem in 3 gezeigten Prozess ist jedoch keine der gestarteten Transaktionen verschachtelt.
Weil X1 zusammengebrochen ist, empfängt C keine Antwort von X1 innerhalb der vorbestimmten Zeitperiode. Als Konsequenz wählt C ein neues primäres Exemplar von X ("X2") aus und sendet die Anforderung (die rid1 enthält) an X2. Auf den Empfang des Aufrufs hin führt X2 eine Nachschlag-Operation aus, um festzustellen, ob ein Protokoll eine Aufzeichnung enthält, die mit rid1 in Beziehung steht. Im vorliegenden Beispiel enthält das Protokoll keine mit rid1 in Beziehung stehende Aufzeichnung, weil jede Protokoll-Aufzeichnung, die von X1 für rid1 erzeugt worden wäre, lediglich als Teil einer Transaktion erzeugt worden wäre, die niemals bestätigt worden ist. Konsequenterweise wäre jede derartige Aufzeichnung beim Rückabwickeln der Transaktion aus dem Protokoll entfernt worden. In ähnlicher Weise wären die Wirkungen aller Operationen, die von X1 als Antwort auf die mit rid1 in Beziehung stehende Anforderung vor der Fehlfunktion von X1 ausgeführt wurden, ebenso rückgängig gemacht worden.
Auf das Feststellen hin, dass das Protokoll keine Aufzeichnung für rid1 enthält, beginnt X2 die Transaktion und verarbeitet dann die Anforderung als Teil der Transaktion. Während des Verarbeitens der Anforderung ruft X2 Y1 mit einer Anforderung, die den Anforderungsbezeichner rid2 enthält, auf. Auf den Empfang des Aufrufes hin, führt Y1 eine Nachschlag-Operation aus, um festzustellen, ob ein Protokoll eine mit rid2 in Beziehung stehende Aufzeichnung enthält. Im vorliegenden Beispiel enthält das Protokoll eine mit rid2 in Beziehung stehende Aufzeichnung, weil eine mit rid2 in Beziehung stehende Aufzeichnung von Y1 in einer Transaktion, die bestätigt worden ist, bevor X1 fehlerhaft war, protokolliert wurde. Die Wirkungen aller Operationen, die von Y1 als Antwort auf die mit rid2 in Beziehung stehende Anforderung vor der Fehlfunktion von Y1 ausgeführt worden sind, sind ebenfalls bestätigt.
Auf das Feststellen hin, dass das Protokoll eine Aufzeichnung für rid2 aufweist, liest Y1 die Antwort aus der Aufzeichnung und überträgt die Antwort an X2 als Antwort auf die Anforderung von X2. Y1 führt keine weitere Verarbeitung als Reaktion auf die Anforderung von X2 aus. Nach dem Empfang der Antwort von Y1 protokolliert X2 eine Aufzeichnung für rid1, welche die Antwort auf die mit rid1 in Beziehung stehende Anforderung enthält. Dann bestätigt X1 die Transaktion und sendet seine Antwort an C.
Bei der in 6 dargestellten Reigenfolge der Ereignisse wird angenommen, dass das Objekt X deterministisch ist. Weil das Objekt X deterministisch ist, ist das Objekt Y in der Lage, seine Veränderungen zu bestätigen, ohne darauf zu achten, ob das Objekt X erfolgreich bestätigen kann. Weil das Objekt X deterministisch ist, kann das Objekt Y sicher sein, dass selbst dann, wenn das gegenwärtige primäre Exemplar des Objektes X beim Bestätigen fehlerhaft ist, ein nachfolgendes primäres Exemplar des Objektes X (1) dieselbe Anforderung an das Objekt Y sendet und (2) seine Transaktion bestätigt. Wenn das Objekt X nicht-deterministisch ist, dann wird eine verschachtelte Transaktion verwendet, wie nun mit Bezug auf 7 beschrieben werden soll.
FEHLFUNKTION VON X1 VOR DEM BESTÄTIGEN UND NACH DEM AUFRUFEN VON Y1, WOBEI X NICHT-DETERMINISTISCH IST
7 ist ein Blockdiagramm, das die Reihenfolge der Ereignisse darstellt, wenn ein spezieller Fehlertyp in einem Aufrufbaum mit drei Einheiten auftritt, wobei die Clients und primären Exemplare derart konfiguriert sind, dass sie so arbeiten, wie es in 2A bzw. 2B dargestellt ist. Der spezielle in 7 dargestellte Fehler ist die Fehlfunktion von X1 nach dem Aufrufen von Y1, aber bevor X1 seine Transaktion bestätigt, wobei X ein nicht-deterministisches Objekt ist. Die Reihe der Ereignisse ist bis vor dem Punkt, an dem Y1 seine Transaktion bestätigt, mit dem in 3 gezeigten Szenario ohne Fehlfunktion identisch. Jedoch ist die von Y1 gestartete Transaktion eine verschachtelte Transaktion innerhalb der Transaktion TX1, die innerhalb X1 ausgeführt wird, das den Aufruf von Y1 getätigt hat. Konsequenterweise wird die von Y1 gestartete verschachtelte Transaktion rückabgewickelt, wenn TX1 rückabgewickelt wird.
Nach dem Komplettieren aller Verarbeitungen bestätigt Y1 und sendet eine Antwort an X1. Weil X1 zusammengebrochen ist, empfängt C keine Antwort von X1 innerhalb der vorbestimmten Zeitperiode. Konsequenterweise wählt C ein neues primäres Exemplar von X ("X2") und sendet die Anforderung (die rid1 enthält) an X2. Auf den Empfang der Anforderung hin führt X2 eine Nachschlag-Operation aus, um festzustellen, ob ein Protokoll eine mit rid1 in Beziehung stehende Aufzeichnung enthält. Im vorliegenden Beispiel enthält das Protokoll keine mit rid1 in Beziehung stehende Aufzeichnung, weil jede von X1 erzeugte Protokoll-Aufzeichnung für rid1 als Teil der Transaktion TX1 erzeugt worden wäre, die niemals bestätigt wurde. Konsequenterweise wäre jede derartige Aufzeichnung beim Rückabwickeln von TX1 aus dem Protokoll entfernt worden. In ähnlicher Weise wären auch alle Wirkungen aller Operationen, die von X1 vor seiner Fehlfunktion als Antwort auf die mit rid1 in Beziehung stehende Anforderung ausgeführt wurden, ebenso rückgängig gemacht worden, und die Wirkungen jeder Operation, die von Y1 als Reaktion auf die mit rid2 in Beziehung stehende Anforderung ausgeführt wurden, wären ebenfalls rückgängig gemacht worden.
Auf die Feststellung hin, dass das Protokoll keine Aufzeichnung für rid1 enthält, beginnt X2 eine neue Transaktion TX2 und verarbeitet die Anforderung dann als Teil der Transaktion. Während des Verarbeitens der Anforderung kann X2 Y1 aufrufen, muss aber nicht. Weil das Objekt X nicht-deterministisch ist, können sich die Faktoren, welche X1 dazu veranlasst haben, Y1 aufzurufen, geändert haben, wodurch X2 veranlasst wird, dieselbe Anforderung von C zu verarbeiten, ohne Y aufzurufen. Im in 7 dargestellten Szenario verarbeitet X2 die Anforderung von C, ohne Y1 aufzurufen. Nach dem Durchführen der Operationen, die benötigt werden, um die Anfor derung zu verarbeiten, protokolliert X2 eine Aufzeichnung für rid1, welche die Antwort auf die mit rid1 verbundene Anforderung enthält. X1 bestätigt dann TX2 und sendet das Ergebnis an C.
Weil die von Y1 ausgeführten Operationen Teil einer verschachtelten Transaktion innerhalb von TX1 waren und TX1 nicht bestätigt worden ist, werden die Operationen, die von Y1 durchgeführt worden sind, rückabgewickelt. Konsequenterweise wurde das System in einen konsistenten Zustand zurückgebracht, obwohl X2 Y1 nach dem Zusammenbruch von X1 nicht aufgerufen hat.
SICHERUNGSPUNKTE
In den oben dargestellten Ausführungsbeispielen wird eine verschachtelte Transaktion dazu verwendet, Operationen in Objekten auszuführen, die von nichtdeterministischen Objekten aufgerufen werden, um zu garantieren, dass (1) verschachtelte Aufrufe rückabgewickelt werden, wenn die Transaktionen, in denen sie verschachtelt sind, eine Fehlfunktion aufweisen, und dass (2) verschachtelte Aufrufe rückabgewickelt werden können, wenn sie fehlerhaft sind, ohne die Transaktion, in der sie verschachtelt sind, rückabzuwickeln. Jedoch können anstelle oder zusätzlich zu verschachtelten Transaktionen andere Mechanismen verwendet werden, um diese Ergebnisse zu erzielen. Zum Beispiel können verschachtelte Transaktionen durch Mechanismen wie etwa Sicherungspunkte ersetzt werden, wobei der Kontext der Transaktion in verschachtelten Anforderungen verbreitet wird.
Sicherungspunkte sind Zwischenmarkierungen, die dazu verwendet werden, Stellen innerhalb von Transaktionen zu spezifizieren. Wenn ein Fehler während der Verarbeitung einer Transaktion, welche eine oder mehrere Sicherungspunkte enthält, auftritt, dann wird die Transaktion zum letzten Sicherungspunkt in der Transaktion rückabgewickelt, anstatt sie den gesamten Weg bis zum Anfang der Transaktion rückabzuwickeln.
In einer Ausführungsform, welche einen Sicherungspunkt verwendet, kann ein Aufruf des Objekts vor dem Aufrufen eines weiteren Objekts einen Sicherungspunkt setzen, oder das aufgerufene Objekt kann einen Sicherungspunkt setzen, bevor es Arbeit als Reaktion auf den Aufruf ausführt. Alle vom aufgerufenen Objekt als Reaktion auf den Aufruf durchgeführten Operationen werden als Teil derjenigen Transaktion, die durch den Aufruf des Objektes ausgeführt wird, ausgeführt. Wenn das primäre Exemplar des aufgerufenen Objektes eine Fehlfunktion aufweist, dann wird die Transaktion bis zum Sicherungspunkt vor dem Aufruf rückabgewickelt. Das aufrufende Objekt kann dann den Aufruf an ein neu ausgewähltes primäres Exemplar des aufgerufenen Objektes neu ausgeben, ohne alle Operationen, die vom aufrufenden Objekt vor dem Sicherungspunkt durchgeführt worden sind, rückabzuwickeln.
Ausführungsformen können die hierin beschriebenen Techniken realisieren, ohne Sicherungspunkte oder verschachtelte Transaktionen einzusetzen. In Ausführungsformen, welche keine verschachtelten Transaktionen oder Sicherungspunkte verwenden, können die von X und Y ausgeführten Operationen als Teil einer einzelnen Transaktion ausgeführt werden. Unter diesen Umständen würde eine Fehlfunktion des primären Exemplars entweder von X oder von Y zu einem Rückabwickeln aller Änderungen, sowohl der von X als auch der von Y ausgeführten, führen. Dies kann dazu führen, dass einige der Operationen, die rückabgewickelt wurden, neu ausgeführt werden müssen, wobei solch ein Neuausführen durch das Verwenden von verschachtelten Transaktionen oder Sicherungspunkten hätte vermieden werden können.
ANNAHMEN UND VARIATIONEN
In den oben beschriebenen Techniken wird angenommen, dass alle Exemplare des replizierten Objektes auf dasselbe Protokoll zugreifen können. Das Protokoll kann z.B. eine gemeinsam benutzte Datenbank sein, die dazu verwendet wird, Nachrichten zu protokollieren. Die gemeinsam verwendete Datenbank kann für eine hohe Verfügbarkeit selbst repliziert sein. Außerdem wird in den Techniken angenommen, dass für jedes Objekt Y (egal ob repliziert oder nicht), das von einem Exemplar X, welches diese Technik verwendet (nächstes Objekt im Aufrufpfad) aufgerufen wird, eine der folgenden Aussagen zutrifft: Y verwendet dieselbe Technik und unterstützt verschachtelte Transaktionen (oder ähnliche Mechanismen, wie etwa Sicherungspunkte).
Y verwendet dieselben Techniken und unterstützt einfache Transaktionen. X muss deterministisch sein, wenn Y in seinem Aufruf-Unterbaum Zustandsänderungen enthält.
Y ist deterministisch und idempotent oder erscheint so (beispielsweise verwirft es Duplikate und gibt immer dieselbe Antwort aus). X muss deterministisch sein, wenn Y in seinem Aufruf-Unterbaum eine Zustandsänderung enthält.
In der oben gegebenen Beschreibung wurde ausgeführt, dass das aufrufende Objekt ein neues primäres Exemplar des aufgerufenen Objektes auswählt, wenn das gegenwärtige primäre Exemplar des aufgerufenen Objektes eine Fehlfunktion aufweist. Das Auswählen eines neuen primären Exemplars kann jedoch in einer Vielzahl von Wegen ausgeführt werden. Zum Beispiel können in einer Ausführungsform die verbleibenden Exemplare untereinander aushandeln, welches Exemplar das primäre Exemplar sein soll. Wenn ein aufrufendes Objekt ein anderes als das neue primäre Exemplar aufruft, kann das aufgerufene Exemplar einfach antworten, indem es dem aufrufenden Objekt Daten sendet, welche das neue primäre Exemplar identifizieren. Das aufrufende Objekt kann dann das richtige neue Exemplar aufrufen.
Die hierin beschriebenen Techniken können mit einer Vielzahl anderer passiver Replikationstechniken kombiniert werden. Zum Beispiel kann eine beliebige Anzahl wohlbekannter Techniken dazu verwendet werden, als Reaktion auf eine Fehlfunktion ein neues primäres Exemplar auszuwählen und dem neuen primären Exemplar den Zustand eines fehlerhaften Exemplars mitzuteilen. In ähnlicher Weise kann eine beliebige Anzahl Techniken dazu verwendet werden, Aufzeichnungen zu generieren und zu protokollieren und den Exemplaren eines replizierten Objektes einen gemeinsamen Zugriff auf das Protokoll zur Verfügung zu stellen.
ÜBERBLICK ÜBER DIE HARDWARE
8 ist ein Blockdiagramm, das ein Computersystem 800 darstellt, auf welchem eine Ausführungsform der Erfindung realisiert werden kann. Das Computersystem 800 schließt einen Bus 802 oder einen anderen Kommunikationsmechanismus zum Weiterleiten von Information und einen mit dem Bus 802 verbundenen Prozessor 804 zum Verarbeiten von Information ein. Das Computersystem 800 schließt außerdem einen mit dem Bus 802 verbundenen Hauptspeicher 806, wie etwa einen Direktzugriffsspeicher (RAM, random access memory) oder eine andere dynamische Speichervorrichtung zum Speichern von Information und Instruktionen, die vom Prozessor 804 auszuführen sind, ein. Der Hauptspeicher 806 kann auch dazu verwendet werden, während des Ausführens von Instruktionen, welche vom Prozessor 804 auszuführen sind, temporäre Variablen oder andere Zwischeninformationen zu speichern. Das Computersystem 800 schließt außerdem einen mit dem Bus 802 verbundenen Festwertspeicher (ROM, read only memory) 808 oder eine andere statische Speichervorrichtung zum Speichern statischer Informationen und Instruktionen für den Prozessor 804 ein. Eine Speichervorrichtung 810, wie etwa Magnetplatte oder eine optische Speicherplatte ist zum Speichern von Information und von Instruktionen zur Verfügung gestellt und mit dem Bus 802 verbunden.
Das Computersystem 800 kann über den Bus 802 mit einem Display 812, wie etwa einer Kathodenstrahlröhre (CRT, cathode ray tube) zum Darstellen von Information für einen Computernutzer verbunden sein. Eine Eingabevorrichtung 814 einschließlich alphanumerischer oder anderer Tasten ist mit dem Bus 802 zum Übermitteln von Informationen oder zur Auswahl von Befehlen für den Prozessor 804 verbunden. Ein weiterer Typ einer Eingabevorrichtung für einen Nutzer ist eine Zeigersteuervorrichtung (Cursor-Steuervorrichtung) 816, wie etwa eine Maus, ein Trackball oder Richtungstasten für den Zeiger zum Übermitteln von Richtungsinformationen und einer Befehlsauswahl für den Prozessor 804 sowie zum Steuern der Zeigerbewegung auf dem Display 812. Diese Eingabevorrichtung hat typischerweise zwei Freiheitsgrade in zwei axialen Richtungen, einer ersten Achse (z.B. x) und einer zweiten Achse (z.B. y), welche es der Vorrichtung ermöglichen, Positionen in einer Ebene festzulegen.
Die Erfindung bezieht sich auf das Verwenden des Computersystems 800 zum Realisieren der hier beschriebenen Techniken. Gemäß einer Ausführungsform der Erfindung werden diese Techniken vom Computersystem 800 in Folge des Ausführens einer oder mehrerer Folgen mit je einer oder mehreren im Hauptspeicher 806 enthaltenen Instruktion bzw. Instruktionen realisiert. Solche Instruktionen können aus einem anderen computerlesbaren Medium, wie etwa der Speichervorrichtung 810, in den Hauptspeicher 806 eingelesen werden. Das Ausführen der Folgen von Instruktionen, die im Hauptspeicher 806 enthalten sind, veranlasst den Prozessor 804, die hierin beschriebenen Prozessschritte auszuführen. In alternativen Ausführungsformen kann eine hardwaremäßig verdrahtete Schaltung dazu verwendet werden, die Erfindung anstelle von oder in Kombination mit Softwareinstruktionen zu realisieren. Somit sind die Ausführungsformen der Erfindung nicht auf eine spezifische Kombination von hardwaremäßiger Schaltung und Software eingeschränkt.
Der Ausdruck "computerlesbares Medium", wie er hierin verwendet wird, bezieht sich auf jedes Medium, das daran beteiligt ist, den Prozessor 804 mit auszuführenden Instruktionen zu versorgen. Solch ein Medium kann viele Formen annehmen, einschließlich, aber ohne darauf beschränkt zu sein, nicht-flüchtige Medien, flüchtige Medien und Übertragungsmedien. Nicht-flüchtige Medien schließen z.B. optische oder magnetische Speicherplatten, wie etwa die Speichervorrichtung 810, ein. Flüchtige Medien schließen dynamische Speicher, wie etwa den Hauptspeicher 806, ein. Übertragungsmedien schließen Koaxialkabel, Kupferdrähte und Faseroptik ein, einschließlich derjenigen Drähte, die der Bus 802 umfasst. Die Übertragungsmedien können auch die Form von akustischen Wellen oder Lichtwellen annehmen, wie etwa diejenigen, die während einer Funkwellen- oder Infrarotwellendatenübertragung erzeugt werden.
Übliche Formen von computerlesbaren Medien schließen z.B. eine Floppydisk, eine flexible Platte, eine Festplatte, ein Magnetband oder ein beliebiges anderes magnetisches Speichermedium, eine CD-ROM und andere optische Speichermedien, Lochkarten, Papierstreifen und andere physikalische Speichermedien mit Lochmustern, ein RAM, ein PROM, ein EPROM, ein FLASH-EPROM und jeden anderen Speicherchip oder Speicherkassette, eine Trägerwelle, wie sie nachfolgend beschrieben ist, oder jedes andere Medium, von dem ein Computer lesen kann, ein.
Verschiedene Formen von computerlesbaren Medien können daran beteiligt sein, eine oder mehrere Folgen mit einem oder mehreren Befehlen, die vom Prozessor 804 auszuführen sind, zu übermitteln. Zum Beispiel können die Instruktionen ursprünglich auf einer Magnetscheibe eines entfernten Computers enthalten sein. Der entfernte Computer kann die Instruktionen in seinen dynamischen Speicher laden und die Instruktionen unter Verwendung eines Modems über eine Telefonleitung senden. Ein Modem im lokalen Computersystem 800 kann die auf der Telefonleitung vorhandenen Daten empfangen und einen Infrarot-Transmitter dazu verwenden, die Daten in ein Infrarotsignal umzuwandeln. Ein Infrarotdetektor kann die im Infrarotsignal enthaltenen Daten empfangen, und eine geeignete Schaltung kann die Daten auf den Bus 802 einspielen. Der Bus 802 überträgt die Daten dann zum Hauptspeicher 806, von dem der Prozessor 804 die Instruktionen abruft und ausführt. Die vom Hauptspeicher 806 empfangenen Instruktionen können optional entweder vor oder nach der Ausführung durch den Prozessor 804 in der Speichervorrichtung 810 gespeichert werden.
Das Computersystem 800 schließt auch eine an den Bus 802 gekoppelte Kommunikationsschnittstelle 818 ein. Die Kommunikationsschnittstelle 818 ermöglicht eine Zweiwege-Datenkommunikation, die an eine Netzwerkverbindung 820 koppelt, welche mit einem lokalen Netzwerk 822 verbunden ist. Zum Beispiel kann die Kommunikationsschnittstelle 818 eine ISDN-Karte (ISDN, integrated services digital network) oder ein Modem sein, um eine Datenübertragungsverbindung zu einer Telefonleitung einer entsprechenden Art zur Verfügung zu stellen. Als ein weiteres Beispiel kann die Kommunikationsschnittstelle 818 eine LAN-Karte (LAN, local area network) sein, um eine Datenübertragungsverbindung zu einem kompatiblen lokalen Netzwerk (LAN) zur Verfügung zu stellen. Drahtlose Verbindungen können auch realisiert werden. In einer derartigen Realisierung sendet und empfängt die Kommunikationsschnittstelle 818 elektrische, elektromagnetische oder optische Signale, welche digitale Datenströme tragen, die verschiedene Arten von Informationen repräsentieren.
Die Netzwerkverbindung 820 stellt typischerweise eine Datenkommunikation über ein oder mehrere Netzwerke zu anderen Datenvorrichtungen zur Verfügung. Zum Beispiel kann die Netzwerkverbindung 820 über ein lokales Netzwerk 822 eine Verbindung mit einem Hauptcomputer 824 oder mit einer Datenausrüstung, die von einem Internet-Dienstanbieter (ISP, Internet service provider) 826 betrieben wird, zur Verfügung stellen. Der Internet-Dienstanbieter 826 stellt wiederum einen Datenübertragungsdienst über das weltweite Kommunikationsnetzwerk für Datenpakete, welches heutzutage im Allgemeinen als das "Internet" 828 bezeichnet wird, zur Verfügung. Das lokale Netzwerk 822 und das Internet 828 verwenden elektrische, elektromagnetische oder optische Signale, welche digitale Datenströme tragen. Die Signale durch die verschiedenen Netzwerke, die Signale auf der Netzwerkverbindung 820 und durch die Kommunikationsschnittstelle 818, welche alle die digitale Daten vom und zum Computersystem 800 tragen, sind beispielhafte Formen für Trägerwellen, welche die Information transportieren.
Das Computersystem 800 kann über das Netzwerk bzw. die Netzwerke, die Netzwerkverbindung 820 und die Kommunikationsschnittstelle 818 Nachrichten senden und Daten einschließlich Programmcodes abrufen. Im Internet-Beispiel kann ein Server 830 einen angeforderten Code für ein Anwendungsprogramm über das Internet 828, den Internet-Dienstanbieter 826, das lokale Netzwerk 822 und die Kommunikationsschnittstelle 818 übertragen. Gemäß der Erfindung realisiert eine derart abgerufene Anwendung die hierin beschriebenen Techniken.
Der empfangene Code kann vom Prozessor 804 beim Empfang ausgeführt werden oder in der Speichervorrichtung 810 oder einem anderen nicht-flüchtigen Speicher zur späteren Ausführung gespeichert werden. In dieser Weise kann das Computersystem 800 den Anwendungscode in Form einer Trägerwelle erhalten.
In der vorangegangenen Beschreibung wurde die Erfindung mit Bezug auf spezifische Ausführungsformen beschrieben. Es ist jedoch ersichtlich, dass zahlreiche Modifikationen und Änderungen vorgenommen werden können, ohne den Rahmen der Ansprüche zu verlassen. Die Beschreibung und die Zeichnungen sollen dement sprechend in einem darstellenden Sinn statt einem einschränkenden Sinn verstanden werden.

Claims

Verfahren zum Ausführen einer Operation, bei der ein Client (C) ein repliziertes Objekt (X) aufruft (202), wobei das Verfahren die Schritte umfasst: Empfangen (250) einer ersten Anforderung von dem Client (C) bei einem primären Exemplar (X1) des replizierten Objekts, wobei die erste Anforderung einen Anforderungsbezeichner aufweist; Bestimmen (252), ob eine Aufzeichnung existiert, die dem Anforderungsbezeichner entspricht; wenn eine dem Anforderungsbezeichner entsprechende Aufzeichnung existiert, dann Beantworten (258) der ersten Anforderung durch das primäre Exemplar (X1) mit einer Antwort, die mit der Aufzeichnung in Beziehung steht; wenn keine dem Anforderungsbezeichner entsprechende Aufzeichnung existiert, dann Ausführen der folgenden Schritte durch das primäre Exemplar (X1): Starten (254) einer Transaktion; als Teil der Transaktion ausgeführtes Bearbeiten (256, 260) der ersten Anforderung; als Teil der Transaktion ausgeführtes Speichern (262) einer dem Anforderungsbezeichner zugeordneten Aufzeichnung und Speichern (262) einer Antwort auf die erste Anforderung; Bestätigen (264) der Transaktion; und Übermitteln (266) der Antwort an den Client (C).
Verfahren nach Anspruch 1, bei dem der Schritt des Bearbeitens (256, 260) der ersten Anforderung das Ausführen von Logikoperationen umfasst, um zu bestimmen, welche Vorgänge auszuführen sind, und zwar zumindest zum Teil auf der Grundlage eines oder mehrerer Faktoren, die sich unterscheiden von dem Zustand des primären Exemplars (X1) beim Empfang der ersten Anforderung; und dem Inhalt der ersten Anforderung.
Verfahren nach Anspruch 1, bei dem der Schritt des Bearbeitens (256, 260) der ersten Anforderung die Schritte umfasst: Senden (256) einer zweiten Anforderung an einen Server; und Empfangen (260) einer zweiten Antwort von dem Server in Reaktion auf die zweite Anforderung.
Verfahren nach Anspruch 3, bei dem: der Server ein zweites repliziertes Objekt (Y) ist; es der Schritt des Sendens (256) der zweiten Anforderung an den Server umfasst, die folgenden Schritte wiederholt auszuführen, bis eine Antwort von einem Exemplar des zweiten replizierten Objekts (Y) erhalten wird: Senden der zweiten Anforderung an das primäre Exemplar (Y1) des zweiten replizierten Objekts (Y); und wenn das primäre Exemplar (Y1) des zweiten replizierten Objekts (Y) nicht innerhalb eines vorbestimmten Zeitabschnitts antwortet, dann Auswählen eines anderen Exemplars (Y2) des zweiten replizierten Objekts (Y) als neues primäres Exemplar.
Verfahren nach Anspruch 2, bei dem der Schritt des Bearbeitens (256, 260) der ersten Anforderung den Schritt umfasst, ein primäres Exemplar (Y1) eines zweiten replizierten Objekts (Y) zu veranlassen, eine Operation in einer verschachtelten Transaktion der Transaktion auszuführen.
Verfahren nach Anspruch 1, bei dem: der Client (C) deterministisch ist; und der Schritt des Startens (254) einer Transaktion ausgeführt wird, indem eine Transaktion gestartet wird, die nicht in irgendeine auf dem Client (C) laufende Transaktion eingebettet ist oder Teil einer solchen Transaktion ist.
Verfahren nach Anspruch 1, bei dem: der Client (C) nicht-deterministisch ist; die erste Anforderung als Teil einer auf dem Client (C) laufenden Transaktion an das primäre Exemplar (X1) gesendet wird; und der Schritt des Startens (254) einer Transaktion ausgeführt wird, indem eine Transaktion gestartet wird, die Teil der auf dem Client (C) laufenden Transaktion ist.
Verfahren nach Anspruch 7, ferner mit dem Schritt, einen Sicherungspunkt zu erstellen, bevor das primäre Exemplar (X1) den Schritt des Bearbeitens (256, 260) der ersten Anforderung ausführt.
Verfahren nach Anspruch 1, bei dem: der Client (C) nicht-deterministisch ist; die erste Anforderung als Teil einer auf Client (C) laufenden Transaktion an das primäre Exemplar (X1) gesendet wird; und der Schritt des Startens (254) einer Transaktion ausgeführt wird, indem eine Transaktion gestartet wird, die in die auf dem Client (C) laufende Transaktion verschachtelt ist.
Computerlesbares Medium mit Befehlen zum Ausführen einer Operation, bei der ein Client (C) ein repliziertes Objekt (X) aufruft, wobei die Befehle solche Befehle umfassen, die zum Ausführen der folgenden Schritte eingerichtet sind: Empfangen (250) einer ersten Anforderung von dem Client (C) bei einem primären Exemplar (X1) des replizierten Objekts (X), wobei die erste Anforderung einen Anforderungsbezeichner aufweist; Bestimmen (252), ob eine Aufzeichnung existiert, die dem Anforderungsbezeichner entspricht; wenn eine dem Anforderungsbezeichner entsprechende Aufzeichnung existiert, dann Beantworten (258) der ersten Anforderung durch das primäre Exemplar (X1) mit einer Antwort, die mit der Aufzeichnung in Beziehung steht; wenn keine dem Anforderungsbezeichner entsprechende Aufzeichnung existiert, dann Ausführen der folgenden Schritte durch das primäre Exemplar (X1): Starten (254) einer Transaktion; als Teil der Transaktion ausgeführtes Bearbeiten (256, 260) der ersten Anforderung; als Teil der Transaktion ausgeführtes Speichern (262) einer dem Anforderungsbezeichner zugeordneten Aufzeichnung und Speichern (262) einer Antwort auf die erste Anforderung; Bestätigen (264) der Transaktion; und Übermitteln (266) der Antwort an den Client (C).
Computerlesbares Medium nach Anspruch 10, bei dem der Schritt des Bearbeitens (256, 260) der ersten Anforderung das Ausführen von Logikoperationen umfasst, um zu bestimmen, welche Vorgänge auszuführen sind, und zwar zumindest zum Teil auf der Grundlage eines oder mehrerer Faktoren, die sich unterscheiden von dem Zustand des primären Exemplars (X1) beim Empfang der ersten Anforderung; und dem Inhalt der ersten Anforderung.
Computerlesbares Medium nach Anspruch 10, bei dem der Schritt des Bearbeitens (256, 260) der ersten Anforderung die Schritte umfasst: Senden (256) einer zweiten Anforderung an einen Server; und Empfangen (260) einer zweiten Antwort von dem Server in Reaktion auf die zweite Anforderung.
Computerlesbares Medium nach Anspruch 12, bei dem: der Server ein zweites repliziertes Objekt (Y) ist; es der Schritt des Sendens (256) der zweiten Anforderung an den Server umfasst, die folgenden Schritte wiederholt auszuführen, bis eine Antwort von einem Exemplar des zweiten replizierten Objekts (Y) erhalten wird: Senden der zweiten Anforderung an das primäre Exemplar (Y1) des zweiten replizierten Objekts (Y); und wenn das primäre Exemplar (Y1) des zweiten replizierten Objekts (Y) nicht innerhalb eines vorbestimmten Zeitabschnitts antwortet, dann Auswählen eines anderen Exemplars (Y2) des zweiten replizierten Objekts (Y) als neues primäres Exemplar.
Computerlesbares Medium nach Anspruch 11, bei dem der Schritt des Bearbeitens (256, 260) der ersten Anforderung den Schritt umfasst, ein primäres Exemplar (Y1) eines zweiten replizierten Objekts (Y) zu veranlassen, eine Operation in einer verschachtelten Transaktion der Transaktion auszuführen.
Computerlesbares Medium nach Anspruch 10, bei dem: der Client (C) deterministisch ist; und der Schritt des Startens (254) einer Transaktion ausgeführt wird, indem eine Transaktion gestartet wird, die nicht in irgendeine auf dem Client (C) laufende Transaktion eingebettet ist oder Teil einer solchen Transaktion ist.
Computerlesbares Medium nach Anspruch 10, bei dem: der Client (C) nicht-deterministisch ist; die erste Anforderung als Teil einer auf dem Client (C) laufenden Transaktion an das primäre Exemplar (X1) gesendet wird; und der Schritt des Startens (254) einer Transaktion ausgeführt wird, indem eine Transaktion gestartet wird, die Teil der auf dem Client (C) laufenden Transaktion ist.
Computerlesbares Medium nach Anspruch 16, ferner mit Befehlen zum Ausführen des Schritts, einen Sicherungspunkt zu erstellen, bevor das primäre Exemplar (X1) den Schritt des Bearbeitens (256, 260) der ersten Anforderung ausführt.
Computerlesbares Medium nach Anspruch 10, bei dem: der Client (C) nicht-deterministisch ist; die erste Anforderung als Teil einer auf Client (C) laufenden Transaktion an das primäre Exemplar (X1) gesendet wird; und der Schritt des Startens (254) einer Transaktion ausgeführt wird, indem eine Transaktion gestartet wird, die in die auf dem Client (C) laufende Transaktion verschachtelt ist.
System zum Ausführen einer Operation, das umfasst: einen Client (C), der dazu eingerichtet ist, eine erste Anforderung an ein repliziertes Objekt (X) zu senden, wobei die erste Anforderung einen Anforderungsbezeichner aufweist; ein primäres Exemplar (X1) des replizierten Objekts, das dazu eingerichtet ist, auf die erste Anforderung zu antworten, indem die folgenden Schritte ausgeführt werden: Bestimmen, ob eine Aufzeichnung existiert, der dem Anforderungsbezeichner entspricht; wenn eine dem Anforderungsbezeichner entsprechende Aufzeichnung existiert, dann Beantworten der ersten Anforderung durch das primäre Exemplar (X1) mit einer Antwort, die mit der Aufzeichnung in Beziehung steht; wenn keine dem Anforderungsbezeichner entsprechende Aufzeichnung existiert, dann Ausführen der folgenden Schritte durch das primäre Exemplar (X1): Starten einer Transaktion; als Teil der Transaktion ausgeführtes Bearbeiten der ersten Anforderung; als Teil der Transaktion ausgeführtes Speichern einer dem Anforderungsbezeichner zugeordneten Aufzeichnung und Speichern einer Antwort auf die erste Anforderung; Bestätigen der Transaktion; und Übermitteln der Antwort an den Client (C).
System nach Anspruch 19, bei dem das primäre Exemplar (X1) dazu eingerichtet ist, die erste Anforderung durch Ausführen von Logikoperationen zu bearbeiten, die bestimmen, welche Vorgänge auszuführen sind, und zwar zumindest zum Teil auf der Grundlage eines oder mehrerer Faktoren, die sich unterscheiden von dem Zustand des primären Exemplars (X1) beim Empfang der ersten Anforderung; und dem Inhalt der ersten Anforderung.
System nach Anspruch 19, ferner mit: einem Server; wobei das primäre Exemplar (X1) dazu eingerichtet ist, die erste Anforderung durch das Ausführen von Aktionen zu bearbeiten, die die folgenden Aktionen umfassen: Senden einer zweiten Anforderung an den Server; und Empfangen einer zweiten Antwort von dem Server in Reaktion auf die zweite Anforderung.
System nach Anspruch 21, bei dem: der Server ein zweites repliziertes Objekt (Y) ist; das primäre Exemplar (X1) dazu eingerichtet ist, die folgenden Schritte wiederholt auszuführen, bis eine Antwort von einem Exemplar des zweiten replizierten Objekts (Y) erhalten wird: Senden der zweiten Anforderung an das primäre Exemplar (Y1) des zweiten replizierten Objekts (Y); und wenn das primäre Exemplar (Y1) des zweiten replizierten Objekts (Y) nicht innerhalb eines vorbestimmten Zeitabschnitts antwortet, dann Auswählen eines anderen Exemplars (Y2) des zweiten replizierten Objekts (Y) als neues primäres Exemplar.
System nach Anspruch 20, bei dem das primäre Exemplar (Y1) eines zweiten replizierten Objekts (Y) dazu eingerichtet ist, auf die zweite Anforderung zu antworten, indem es eine Operation in einer verschachtelten Transaktion der Transaktion ausführt.
System nach Anspruch 19, bei dem: der Client (C) deterministisch ist; und das primäre Exemplar (X1) dazu eingerichtet ist, die Transaktion zu starten, indem eine Transaktion gestartet wird, die nicht in irgendeine auf dem Client (C) laufende Transaktion eingebettet ist oder Teil einer solchen Transaktion ist.
System nach Anspruch 19, bei dem: der Client (C) nicht-deterministisch ist; die erste Anforderung als Teil einer auf dem Client (C) laufenden Transaktion an das primäre Exemplar (X1) gesendet wird; und das primäre Exemplar (X1) dazu eingerichtet ist, die Transaktion zu starten, indem eine Transaktion gestartet wird, die Teil der auf dem Client (C) laufenden Transaktion ist.
System nach Anspruch 25, bei dem ein Sicherungspunkt erstellt wird, bevor das primäre Exemplar (X1) die erste Anforderung bearbeitet.
System nach Anspruch 19, bei dem: der Client (C) nicht-deterministisch ist; die erste Anforderung als Teil einer auf Client (C) laufenden Transaktion an das primäre Exemplar (X1) gesendet wird; und das primäre Exemplar (X1) dazu eingerichtet ist, die Transaktion zu starten, indem eine Transaktion gestartet wird, die in die auf dem Client (C) laufende Transaktion verschachtelt ist.