DE69839145T2 - Kompensierender Betriebsmittelverwalter - Google Patents

Kompensierender Betriebsmittelverwalter Download PDF

Info

Publication number
DE69839145T2
DE69839145T2 DE69839145T DE69839145T DE69839145T2 DE 69839145 T2 DE69839145 T2 DE 69839145T2 DE 69839145 T DE69839145 T DE 69839145T DE 69839145 T DE69839145 T DE 69839145T DE 69839145 T2 DE69839145 T2 DE 69839145T2
Authority
DE
Germany
Prior art keywords
crm
component
transaction
compensator
resource
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69839145T
Other languages
English (en)
Other versions
DE69839145D1 (de
Inventor
Joe Dennis Woodinville Long
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of DE69839145D1 publication Critical patent/DE69839145D1/de
Application granted granted Critical
Publication of DE69839145T2 publication Critical patent/DE69839145T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y10S707/99953—Recoverability

Description

  • Die vorliegende Erfindung betrifft allgemein Verarbeitungsanwendungen für Online-Transaktionen und betrifft insbesondere die Verwaltung von Nicht-Transaktionsressourcen oder nicht konformen Transaktionsressourcen in Transaktionsmanagementsystemen für Verarbeitungsanwendungen für Online-Transaktionen.
  • ALLGEMEINER STAND DER TECHNIK UND KURZDARSTELLUNG DER ERFINDUNG
  • In vielen Datenverarbeitungsanwendungen stellt eine Server-Anwendung, welche auf einem Host- oder Server-Computer in einem verteilten Netzwerk abläuft, Verarbeitungsdienste oder Verfahren für Client-Anwendungen bereit, welche auf Stations- oder Arbeitsplatzcomputern des Netzwerks ablaufen, die von einer Vielzahl Benutzern bedient werden. Ein übliches Beispiel für solche Serveranwendungen ist die Software für die Verarbeitung von Einschreibungen in Kurse an einer Universität, von Reisereservierungen, von Geldtransfers und anderen Diensten einer Bank und von Umsätzen in einem Geschäft. In diesen Beispielen unterhalten die Verarbeitungsdienste, welche von der Server-Anwendung bereitgestellt werden, typischerweise stabile Daten oder „Zustände" von Kursplänen, Hotelreservierungen, Kontoständen, Auftragseingängen, Zahlungen oder Inventar für Aktionen, welche von den einzelnen Benutzern an ihren entsprechenden Stationen initiiert werden, z. B. in einer Datenbank oder einem Datenspeicher eines anderen Betreiberformats.
  • Oft machen Serveranwendungen das Koordinieren von Aktivitäten auf mehreren Computer durch getrennte Prozesse auf einem Computer oder sogar in einem einzelnen Prozess erforderlich. Zum Beispiel kann eine Geldtransferoperation in einer Bankanwendung Aktualisierungen von Kontodaten umfassen, welche in verschiedenen Datenbanken gespeichert sind, die sich auf verschiedenen Computern befinden, welche geographisch voneinander entfernt sein können. Wünschenswerter Weise werden Gruppen von Aktivitäten, welche Teile einer Operation bilden, koordiniert, so daß sie als einzelne unteilbare Arbeitseinheit wirken, welche gewöhnlich als eine Transaktion bezeichnet wird. In vielen Anwendungen wird die Durchführung von Gruppen von Aktivitäten zu einer geschäftlichen Notwendigkeit. Wenn in einer Geldtransferoperation zum Beispiel aufgrund eines Systemfehlers nur ein Konto aktualisiert wird, erzeugt oder vernichtet die Bank im Ergebnis Geld.
  • Eine Transaktion ist eine Zusammenstellung von Aktionen, welche einer Gruppe von Eigenschaften entsprechen, welche Atomarität, Konsistenz, Isolation und Dauerhaftigkeit umfassen und als die „ACID"-Eigenschaften bezeichnet werden. Atomarität bedeutet, daß alle Aktivitäten in einer Transaktion entweder als eine Einheit zusammen wirken oder alle fehlschlagen. Konsistenz bedeutet, daß nach der Ausführung einer Transaktion das System in einem stabilen oder zulässigen Zustand hinterlassen wird (d. h., wenn die Wirkung der Aktivitäten einer Transaktion nicht zu einem zulässigen stabilen Zustand führen würde, wird das System in seinen ursprünglichen Zustand wie vor der Transaktion zurückgeführt). Isolation bedeutet, daß die Transaktion nicht durch irgendwelche anderen gleichzeitig ausgeführten Transaktionen beeinflusst wird (Zugriffe von Transaktionen auf gemeinsame Ressourcen sind durchnummeriert, und Veränderungen gemeinsamer Ressourcen sind außerhalb der Transaktion nicht sichtbar, bis die Transaktion beendet ist). Dauerhaftigkeit bedeutet, daß die Wirkungen einer Transaktion beständig sind und Systemfehler überstehen. Für weitere Hintergrundinformationen über die Transaktionsverarbeitung wird u. a. auf Jim Gray und Andreas Reuter, Transaction Processing Concepts and Techniques, Morgan Kaufmann, 1993, verwiesen.
  • Frühere Patentanmeldungen, welche ebenso auf den Inhaber den vorliegenden Erfindung übertragen sind (namentlich Helland u. a., „Automatic Transaction Processing Of Component-Based Server Applications", US-Patentanmeldung 08/959,141, und Helland u. a., „Disabling And Enabling Transaction Committal In Transaction Application Components", US-Patentanmeldung 08/959,142, beide eingereicht am 28. Oktober 1997, welche hiermit durch Bezugnahme in die vorliegende Patentanmeldung einbezogen werden und hierin im Folgenden zusammengenommen als die „einbezogenen MTS-Patentanmeldungen" bezeichnet werden), offenbaren eine Ausführungsumgebung und Plattform für verteilte Serveranwendungen, welche in dem Produkt Microsoft Transaction Server (MTS), Version 1.0, enthalten ist. MTS stellt ein komponentenbasiertes Gerüst oder Objektmodell mit Systemdiensten bereit, um Transaktionen von möglicherweise verteilten Gruppen von Komponenten von Serveranwendungen unter der Steuerung eines Transaktionsmanagers wie dem Microsoft Distributed Transaction Coordinator (MS DTC) zu unterstützen.
  • Im MTS verwenden Serveranwendungen Ressourcenmanager, um den dauerhaften Zustand der Anwendung beizubehalten, z. B. des Verzeichnisses des verfügbaren Inventars, der zu bearbeitenden Aufträge und der Kontenforderungen. Ressourcenmanager sind Systemdienste, welche dauerhafte Daten verwalten, wie sie z. B. in Datenbanken, dauerhaften Meldungswarteschlangen, Dateisystemen oder anderen Datenspeicherungsressourcen enthalten sein können. Ein Beispiel ist der Ressourcenmanager, welcher mit dem Microsoft SQL Server, Version 6.5, bereitgestellt wird. Ressourcenmanager arbeiten im Zusammenwirken mit dem Transaktionsmanager, um für die dauerhaften Daten der verwalteten Ressource die ACID-Eigenschaften durchzusetzen.
  • Ressourcenmanager sind für eine spezielle Ressource (z. B. dauerhafte Datenspeicher) schwierig zu entwickeln und zu realisieren. Dies liegt daran, daß ein Ressourcenmanager mit einer Anzahl der komplexeren Probleme bei der Transaktionsverarbeitung befasst ist. Insbesondere muß der Ressourcenmanager richtig mit dem Transaktionsmanager verbunden sein und garantieren, daß alle Operationen, für die angefordert wurde, daß sie von Komponenten auf der verwalteten Ressource ausgeführt werden, den ACID-Transaktionseigenschaften entsprechen. Der Ressourcenmanager muß daher sicherstellen, daß alle Aktualisierungen der dauerhaften Daten durch Komponenten, die unter einer speziellen Transaktion beendet werden, dauerhaft gemacht werden, wenn die Transaktion abgeschlossen wird, oder umgekehrt werden, wenn die Transaktion abgebrochen wird. Der Ressourcenmanager verwendet transaktionsbasierte Synchronisierungsprotokolle, um nicht abgeschlossene Arbeitsvorgänge aktiver Transaktionen zu isolieren. Der Ressourcenmanager muß auch die Sicherheit des Teilprozesses gewährleisten, was bedeutet, daß der Ressourcenmanager von Anwendungskomponenten aus jedem Teilprozess aufgerufen werden können muß. Der Ressourcenmanager muß ferner für das Logging und die Wiederherstellung sorgen, so daß Transaktionen, welche die Ressource betreffen, über Abstürze und andere Fehler (Kommunikationsfehler, Verfahrensfehler und Speichermediumsfehler ebenso wie Serversystemfehler) hinweg dauerhaft sind.
  • Ferner muß ein MTS Resource Manager (ein Ressourcenmanager, der dafür geschrieben wurde, MTS zu unterstützen) einigen zusätzlichen Erfordernissen entsprechen. Insbesondere realisiert ein MTS Resource Manager alle (oder eine wesentliche Untermenge der) „OLE-Transactions"-Schnittstellen, welche eine Integration in MTS ermöglichen und mit dem MS DTC verbinden. Außerdem muß ein MTS Resource Manager einen Ressourcendispenser (einen Dienst, welcher für MTS-Server-Anwendungskomponenten ein Pooling und eine automatische Transaktionsteilnahme bietet) für seine verwaltete Ressource bereitstellen. Wenn es keinen Ressourcendispenser gibt, dann muß ein alternativer Mechanismus für die automatische Transaktionsteilnahme bereitgestellt werden.
  • Aufgrund dieser Schwierigkeiten sind bislang noch wenige Ressourcenmanager für MTS erhältlich (ein Beispiel ist der zuvor erwähnte Microsoft SQL Server, Version 6.5). Es ist jedoch derzeit auf dem Markt eine breite Vielfalt von Ressourcen ohne Transaktionsunterstützung erhältlich und im Einsatz. Ferner gibt es eine Vielfalt von Ressourcenmanagern (hierin als Alt-Ressourcenmanager bezeichnet) für andere Transaktionssysteme, welche nicht die erforderlichen Schnittstellen (also die OLE-Transaktionsschnittstellen) bereitstellen, um in MTS zu interoperieren, z. B. mit dem MS DTC zu verbinden. Zum Beispiel weist eine Anzahl von Reservierungssystemen der Reisebranche Reservierungsdatenbanken auf, welche unter dem IBM-CICS-Transaktionssystem verwaltet werden. Es ist deswegen wünschenswert, solche Nicht-Transaktionsressourcen und Alt-Ressourcenmanager einfacher in MTS zu integrieren, als für jede einen spezifischen MTS-Ressourcenmanager zu realisieren.
  • Die US-Patentschrift 5,764,897 offenbart ein Transaktionsmanagerprotokoll und -verfahren, welches von Interprozess-Kommunikationsaktivitäten der Mikrokernels des Betriebssystems unabhängig ist. Der Transaktionsmanager erzeugt Transaktionen, verfolgt alle Objektmanager, welche Teil der Transaktion sind, und koordiniert die Transaktionsbeendigung unter allen Objekten, welche in die Transaktion eingebunden sind. Es können Objekte mit der Transaktion verbunden werden, und dann werden Befehle von dem Transaktionsmanager zu dem Objekt gesendet, eine Operation durchzuführen und diese Operation umzukehren, wenn die Transaktion abgebrochen wird.
  • Die vorliegende Erfindung stellt eine Form eines Ressourcenmanagement bereit (hierin als „Kompensation" oder „kompensierendes Ressourcenmanagement" bezeichnet), welches ermöglicht, daß dauerhafte Ressourcen einfacher in ein Transaktionssystem und insbesondere in eine komponentenbasierte Online-Transaktionsverarbeitungs-Anwendungsumgebung wie MTS integriert werden. Beim kompensierenden Ressourcenmanagement wird eine dauerhafte Ressource integriert, um an Transaktionen unter dem Transaktionssystem teilzunehmen, indem für eine kompensierende Aktion gesorgt wird, um jede normale Aktion umzukehren, welche als Teil einer Transaktion an der Ressource durchgeführt wird. Die normale Aktion wird an der Ressource zum Zeitpunkt der Anforderung persistent gemacht. In dem Fall, daß die Transaktion abgebrochen wird, wird die kompensierende Aktion außerhalb der Transaktion aufgerufen, um die dauerhafte Ressource in ihren Zustand vor der Transaktion zurückzubringen. Für die Dauerhaftigkeit werden Informationen, welche für jede normale Aktion, die während einer Transaktion durchgeführt wird, die vorzunehmende kompensierende Aktion identifizieren, auf einer Vorabeintragungs-Basis in ein Log geschrieben. Somit kann im Fall eines Fehlers die Wiederherstellung gemäß dem Status der Transaktion durchgeführt werden.
  • In einer komponentenbasierten Online-Transaktionsverarbeitungs-Anwendungsumgebung wie MTS kann das kompensierende Ressourcenmanagement für eine spezielle dauerhafte Ressource bereitgestellt werden, indem ein kompensierender Ressourcenmanager (CRM) realisiert wird. In dem CRM realisiert ein Entwickler eine kompensierende Aktion für jede normale Aktion, welche der CRM an der dauerhaften Ressource unterstützt. Der Entwickler realisiert auch, daß der CRM in Verbindung mit jeder normalen Aktion ein Vorabeintragungs-Logging durchführt, um die kompensierende Aktion für diese normale Aktion festzulegen.
  • Gemäß einer Ausführungsform der Erfindung, welche hierin dargestellt wird (die dargestellte Ausführungsform), ist der CRM als Paar von Komponenten, CRM-Arbeitsprogramm und CRM-Kompensator entwickelt, welche nur über das Medium des Logs ihren Zustand (d. h. ihre Daten) teilen. Das CRM-Arbeitsprogramm führt zum Zeitpunkt der Anforderung durch eine Serveranwendung die normale Aktion als Teil einer Transaktion für die Serveranwendung durch. Diese Aktion und eine Schnittstelle, über welche durch die Serveranwendung auf die Aktion zugegriffen werden kann, sind für den speziellen CRM spezifisch. Wenn die Serveranwendung die normale Aktion über die Schnittstelle aufruft, schreibt das CRM-Arbeitsprogramm auch einen Log-Datensatz in ein von dem System bereitgestelltes Log, welcher den CRM-Kompensator identifiziert.
  • Der CRM-Kompensator realisiert die kompensierende Aktion, welche der normalen Aktion des CRM-Arbeitsprogramms entspricht. Der CRM-Kompensator, welcher durch das CRM-Arbeitsprogramm bestimmt wurde, wird später erzeugt, um an späteren Phasen des Zweiphasen-Abschlussprotokolls (z. B. Phase 1 und Phase 2) teilzunehmen, indem geeignete weitere Aktionen in Bezug auf die normale Aktion vorgenommen werden, welche von dem CRM-Arbeitsprogramm geloggt wurden. Der CRM-Kompensator unterstützt eine systemdefinierte Schnittstelle, über welche er Zweiphasen-Abschlussprotokoll-Notifikationen (z. B. Vorbereitungs-, Abschluss- und Abbruchs-Notifikationen) vom Transaktionsmanager empfängt (in der dargestellten Ausführungsform mittels eines Log-Wiederherstellungsmanagers). Diese Notifikationen ermöglichen dem CRM-Kompensator, an diesen Phasen des Zweiphasen-Abschlussprotokolls teilzunehmen.
  • Insbesondere kann der CRM-Kompensator während der Vorbereitungsphase gegen den Abschluss der Transaktion stimmen und in Reaktion auf die Vorbereitungsnotifikation einen Abbruch erzwingen (z. B., indem er in Reaktion auf die Vorbereitungsnotifikation einen Wert zurücksendet, um mit „Nein" zu stimmen). Die Abschlussnotifikation eröffnet dem CRM-Kompensator eine Möglichkeit, nach der normalen Aktion des CRM-Arbeitsprogramms eine Reinigungsverarbeitung durchzuführen. Bei dieser Reinigungsverarbeitung handelt es sich um die Entfernung jedes Zustands (dauerhaft oder nicht dauerhaft), welcher zu Zwecken der Kompensierung einer abgebrochenen Transaktion bewahrt wurde. Die Abschlussnotifikation eröffnet dem Kompensator auch die Möglichkeit, jede Arbeitsvorgang durchzuführen, welcher irreversibel ist. Zum Beispiel kann in einer Transaktion an einem Geldausgabegerät ein Konto belastet werden und Bargeld ausgegeben werden. Es ist nicht wünschenswert, Bargeld auszugeben, solange nicht garantiert ist, daß die Belastung vorgenommen ist. Mit einem CRM, welcher das Geldausgabegerät verwaltet, würde ein CRM-Kompensator in Reaktion auf eine Vorbereitungsnotifikation mit „Ja" stimmen, solange in dem Geldausgabegerät genug physisches Bargeld vorhanden ist. Dann veranlasst der CRM-Kompensator in Reaktion auf eine Abschlussnotifikation, daß das Geldausgabegerät tatsächlich das Bargeld ausgibt. In Reaktion auf die Abbruchsnotifikation führt der CRM-Kompensator die kompensierende Aktion durch, um die normale Aktion des CRM-Arbeitsprogramms umzukehren. Dementsprechend nimmt der CRM-Kompensator während der normalen Verarbeitung einer Transaktion an der Transaktionsvorbereitungsphase teil und wird über den Ausgang der Transaktion unterrichtet. Der CRM-Kompensator kann dann bei Abschluss reinigen oder bei Abbruch kompensieren. Andererseits wird der CRM-Kompensator während der Wiederherstellung erneut erzeugt und über den Ausgang der Transaktion basierend auf dem Log informiert, was dem CRM-Kompensator ermöglicht, die Transaktionsverarbeitung (wenn angebracht) betreffend die Ressource zu beenden, als ob kein Fehler aufgetreten wäre. Wenn zum Beispiel vor einem Systemabsturz die Phase 1 nicht beendet war, wird die Transaktion abgebrochen, und dem CRM-Kompensator wird eine Abbruchsnotifikation übermittelt.
  • In der hier dargestellten Ausführungsform muß jede von dem CRM-Kompensator realisierte Aktion (definiert als die während einer Transaktion verrichtete Arbeit oder als Gruppe von Log-Datensätzen), umfassend insbesondere die kompensierende Aktion, idempotent sein. Dies bedeutet, daß die Aktion des CRM-Kompensators auf einen Abschluss oder einen Abbruch der Transaktion beliebige Male versucht werden kann, und wenn die Aktion einmal erfolgreich ist, erzielt die Aktion dasselbe Ergebnis, als wenn die Aktion beim ersten Versuch erfolgreich gewesen wäre.
  • Weitere Merkmale und Vorteile der Erfindung werden aus der folgenden detaillierten Beschreibung einer dargestellten Ausführungsform ersichtlich, welche sich unter Bezugnahme auf die begleitenden Zeichnungen anschließt.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Blockdiagramm eines dezentralen Computersystems, welches verwendet werden kann, um ein die Erfindung verkörperndes Verfahren und eine die Erfindung verkörpernde Vorrichtung für ein kompensierendes Ressourcenmanagement in einem Online-Transaktionsverarbeitungssystem zu realisieren.
  • 2 ist ein Blockdiagramm einer Serveranwendungs-Ausführungsumgebung mit Diensten für die Transaktionsverarbeitung mit kompensierendem Ressourcenmanagement gemäß der dargestellten Ausführungsform der Erfindung.
  • 3 ist ein Blockdiagramm einer komponentenbasierten Architektur eines kompensierenden Ressourcenmanagers (CRM), welcher in der Serveranwendungs-Ausführungsumgebung zu betreiben ist, um ein kompensierendes Ressourcenmanagement gemäß der dargestellten Ausführungsform der Erfindung bereitzustellen.
  • 4 ist ein Ablaufdiagramm einer Ausführungsreihenfolge innerhalb der CRM-Architektur der 3.
  • 5 ist ein Ablaufdiagramm eines Logging-Verfahrens, welches von einer CRM-Arbeiterkomponente in der Architektur der 3 durchgeführt wird.
  • 6 ist eine Programmauflistung einer „ICrmLogControl"-Schnittstelle auf einem CRM-Clerk in der Architektur des kompensierenden Ressourcenmanagers der 3.
  • 7 ist eine Programmauflistung von Datenstrukturen für eine „ICrmCompensator"-Schnittstelle eines CRM-Kompensators in der Architektur des kompensierenden Ressourcenmanagers der 3.
  • 8 ist eine Programmauflistung einer „ICrmCompensatorVariants"-Schnittstelle des CRM-Kompensators in der Architektur des kompensierenden Ressourcenmanagers der 3.
  • 9 ist eine Programmauflistung einer „ICrmCompensator"-Schnittstelle des CRM-Kompensators in der Architektur des kompensierenden Ressourcenmanagers der 3.
  • 10 ist eine Programmauflistung einer „ILogRecover"-Schnittstelle einer Wiederherstellungsmaschine in der Architektur des kompensierenden Ressourcenmanagers der 3.
  • 11 ist eine Programmauflistung einer „ILogRecoverClerk"-Schnittstelle eines CRM-Wiederherstellungs-Clerks und des CRM-Clerks in der Architektur des kompensierenden Ressourcenmanagers der 3.
  • 12 ist eine Programmauflistung einer „ILogRecoverClerkPhaseNotification"-Schnittstelle des CRM-Wiederherstellungs-Clerks und des CRM-Clerks in der Architektur des kompensierenden Ressourcenmanagers der 3.
  • 13 ist eine Programmauflistung einer „ILogRecoverClerkRegistration"-Schnittstelle der Wiederherstellungsmaschine in der Architektur des kompensierenden Ressourcenmanagers der 3.
  • 14 ist eine Programmauflistung einer „ILog"-Schnittstelle eines Log-Objekts für ein persistentes Log in der Architektur des kompensierenden Ressourcenmanagers der 3.
  • 15 ist eine Programmauflistung einer „ICrmFormatLogRecords"-Schnittstelle in der Architektur des kompensierenden Ressourcenmanagers der 3.
  • 16 ist eine Programmauflistung einer „ICrmMonitorLogRecords"-Schnittstelle des CRM-Clerks in der Architektur des kompensierenden Ressourcenmanagers der 3.
  • 17 ist eine Programmauflistung einer „ICrmMonitorClerks"-Schnittstelle eines Clerk-Zusammenstellungsobjekts in der Architektur des kompensierenden Ressourcenmanagers.
  • 18 ist eine Programmauflistung einer „ICrmMonitor"-Schnittstelle des CRM-Wiederherstellungs-Clerks in der Architektur des kompensierenden Ressourcenmanagers der 3.
  • DETAILLIERTE BESCHREIBUNG DER DARGESTELLTEN AUSFÜHRUNGSFORMEN
  • Die vorliegende Erfindung betrifft Verfahren, Systeme und Softwareprodukte für ein kompensierendes Ressourcenmanagement bei der Online-Transaktionsverarbeitung. In einer hierin dargestellten Ausführungsform ist die Erfindung in Betriebssoftware für Serveranwendungen auf dezentralen Computersystemen mit der Bezeichnung „COM+" integriert, wobei es sich um einen Teil des Betriebssystems „Microsoft Windows NT Server 5.0" von der Microsoft Corporation in Redmond, Washington, handelt. Kurz beschrieben stellt diese Software ein Komponentengerüst und eine Laufzeit-Ausführungsumgebung für Serveranwendungen bereit, welche unter anderem Systemdienste umfaßt, um die Transaktionsverarbeitung zu unterstützen, wobei ein Zweiphasen-Abschlussprotokoll auf dezentralen Computersystemen verwendet wird.
  • Beispielhafte Betriebsumgebung
  • 1 und die folgende Erörterung sollen eine kurze allgemeine Beschreibung einer geeigneten Computerumgebung geben, in welcher die Erfindung realisiert werden kann. Obwohl die Erfindung in dem allgemeinen Zusammenhang computerausführbarer Befehle eines Computerprogramms beschrieben wird, welches auf einem Server-Computer abläuft, wird der Fachmann erkennen, daß die Erfindung auch in Kombination mit anderen Programmmodulen realisiert werden kann. Im Allgemeinen umfassen die Programmmodule Routinen, Programme, Komponenten, Datenstrukturen usw., welche spezielle Aufgaben erfüllen oder spezielle abstrakte Datentypen realisieren. Überdies wird der Fachmann erkennen, daß die Erfindung auch mit anderen Computersystemkonfigurationen ausgeführt werden kann, umfassend Einzel- oder Mehrprozessor-Computersysteme, Minicomputer, Großcomputer ebenso wie Personalcomputer, Handcomputervorrichtungen, Verbraucherelektronik auf Mikroprozessorbasis oder programmierbare Verbraucherelektronik und Ähnliches. Die dargestellte Ausführungsform der Erfindung wird auch in dezentralen Computerumgebungen ausgeführt, wo Aufgaben durch entfernte Verarbeitungsvorrichtungen erfüllt werden, welche über ein Kommunikationsnetzwerk verbunden sind. Einige Ausführungsformen der Erfindung können jedoch auf eigenständigen Computern ausgeführt werden. In einer dezentralen Computerumgebung können sich Programmmodule sowohl auf lokalen als auch auf entfernten Speichervorrichtungen befinden.
  • Bezug nehmend auf 1, umfasst ein beispielhaftes System zur Realisierung der Erfindung einen herkömmlichen Server-Computer 20, umfassend eine Prozessoreinheit 21, einen Systemspeicher 22 und einen Systembus 23, welcher verschiedene Systemkomponenten, darunter den Systemspeicher, mit der Prozessoreinheit 21 verbindet. Bei der Prozessoreinheit kann es sich um irgendeinen der verschiedenen kommerziell erhältlichen Prozessoren handeln, z. B. Intel x86, Pentium und kompatible Mikroprozessoren von Intel und anderen, z. B. Cyrix, AMD und Nexgen; Alpha von Digital; MIPS von MIPS Technology, NEC, IDT, Siemens und anderen und den PowerPC von IBM und Motorola. Duale Mikroprozessoren und andere Mehrprozessorarchitekturen können ebenfalls als Prozessoreinheit 21 verwendet werden.
  • Bei dem Systembus kann es sich um irgendeine von verschiedenen Arten von Busstrukturen handeln, z. B. um einen Speicherbus oder eine Speichersteuerung, einen Peripheriebus oder einen lokalen Bus, wobei irgendeine aus einer Vielfalt von herkömmlichen Busarchitekturen verwendet werden kann, wie z. B. PCI, VESA, Microchannel, ISA und EISA, um nur einige zu nennen. Der Systemspeicher umfasst einen Nur-Lese-Speicher (ROM) 24 und einen Direktzugriffsspeicher (RAM) 25. Ein Basis-Eingabe/Ausgabe-System (BIOS), welches die Basisroutinen enthält, welche dazu beitragen, Informationen zwischen Elementen innerhalb des Server-Computers 20 zu übertragen, z. B. während des Hochfahrens, ist im ROM 24 gespeichert.
  • Der Server-Computer 20 umfasst ferner ein Festplattenlaufwerk 27, ein Magnetplattenlaufwerk 28, um z. B. etwas aus einer Wechselplatte 29 auszulesen oder auf diese zu schreiben, und ein optisches Plattenlaufwerk 30, um z. B. etwas aus einer CD-ROM 31 auszulesen oder etwas aus anderen optischen Medien auszulesen oder auf diese zu schreiben. Das Festplattenlaufwerk 27, das Magnetplattenlaufwerk 28 und das optische Plattenlaufwerk 30 sind über eine Festplattenlaufwerk-Schnittstelle 32, eine Magnetplattenlaufwerk-Schnittstelle 33 bzw. eine Optiklaufwerk-Schnittstelle 34 mit dem Systembus 23 verbunden. Die Laufwerke und ihre zugehörigen computerlesbaren Medien sorgen für eine Speicherung von Daten, Datenstrukturen, computerausführbaren Befehlen usw. für den Server-Computer 20. Obwohl sich die obige Beschreibung von computerlesbaren Medien auf eine Festplatte, eine auswechselbare Magnetplatte und eine CD bezieht, sollte der Fachmann erkennen, daß in der beispielhaften Betriebsumgebung auch andere Arten von Medien verwendet werden können, welche von einem Computer lesbar sind, z. B. Magnetbandcassetten, Flash-Speicher-Karten, DVDs, Bernoulli-Kassetten und Ähnliches.
  • In den Laufwerken und im RAM 25 kann eine Anzahl von Programmmodulen gespeichert werden, z. B. ein Betriebssystem 35, ein oder mehrere Anwendungsprogramme 36, andere Programmmodule 37 und Programmdaten 38. Bei dem Betriebssystem 35 in dem dargestellten Server-Computer handelt es sich um das Betriebssystem Microsoft Windows NT Server zusammen mit dem zuvor erwähnten Microsoft Transaction Server.
  • Ein Benutzer kann Befehle und Informationen über eine Tastatur 40 und eine Zeigervorrichtung, z. B. eine Maus 42, in den Server-Computer 20 eingeben. Andere (nicht dargestellte) Eingabevorrichtungen können z. B. ein Mikrofon, ein Joystick, ein Game Pad, ein Satellitenantenne, ein Scanner oder Ähnliches sein. Diese und andere Eingabevorrichtungen sind mit der Prozessoreinheit 21 oft über eine serielle Schnittstelle 46 verbunden, welche mit dem Systembus verbunden ist, können aber auch über andere Schnittstellen verbunden sein, z. B. eine parallele Schnittstelle, eine Spielschnittstelle oder einen universellen seriellen Bus (USB). Ein Monitor 47 oder eine andere Art der Anzeigevorrichtung ist über eine Schnittstelle, z. B. einen Video-Adapter 48, ebenfalls mit dem Systembus 23 verbunden. Außer dem Monitor umfassen Server-Computer typischerweise andere (nicht dargestellte) periphere Ausgabevorrichtungen, wie z. B. Lautsprecher und Drucker.
  • Der Server-Computer 20 kann in einer Netzwerkumgebung arbeiten, wobei logische Verbindungen zu einem oder mehreren entfernten Computer, z. B. zu einem entfernten Client-Computer 49, verwendet werden. Bei dem entfernten Computer 49 kann es sich um einen Arbeitsplatzrechner, einen Server-Computer, einen Leitwegrechner, eine gleichrangige Vorrichtung oder einen anderen üblichen Netzwerkknoten handeln, und er umfasst typischerweise viele oder alle der in Bezug auf den Server-Computer 20 beschriebenen Elemente, obwohl in 1 nur eine Speichervorrichtung 50 dargestellt ist. Die in 1 abgebildeten logischen Verbindungen umfassen ein lokales Netz (LAN) 51 und ein weiträumiges Netz (WAN) 52. Solche Netzwerkumgebungen sind in Büros, unternehmensweiten Computernetzen, Intranets und dem Internet alltäglich.
  • Wenn er in einer LAN-Netzwerkumgebung verwendet wird, ist der Server-Computer 20 über eine Netzwerk-Schnittstelle oder einen Adapter 53 mit dem lokalen Netz 51 verbunden. Wenn er in einer WAN-Netzwerkumgebung verwendet wird, umfasst der Server-Computer 20 typischerweise ein Modem 54, oder er ist mit einem Kommunikationsserver auf dem LAN verbunden, oder er weist andere Mittel auf, um Kommunikationen über das weiträumige Netz 52, z. B. das Internet, herzustellen. Das Modem 54, bei welchem es sich um ein internes oder ein externes handeln kann, ist über die serielle Schnittstelle 46 mit dem Systembus 23 verbunden. In einer Netzwerkumgebung können in der entfernten Speichervorrichtung Programmmodule, welche in Bezug auf den Server-Computer 20 dargestellt wurden, oder Teile davon gespeichert sein. Man wird erkennen, daß die dargestellten Netzwerkverbindungen beispielhaft sind, und daß andere Mittel zur Herstellung einer Kommunikationsverbindung zwischen den Computer verwendet werden können.
  • Wie es für den Fachmann auf dem Gebiet der Computerprogrammierung üblich ist, wird die vorliegende Erfindung im Folgenden in Bezug auf Maßnahmen und symbolische Darstellungen von Operationen beschrieben, welche von dem Server-Computer 20 durchgeführt werden, solange nicht anders angegeben. Solche Maßnahmen und Operationen werden manchmal als computerausgeführt bezeichnet. Man wird erkennen, daß die Maßnahmen und symbolisch dargestellten Operationen die Manipulation von elektrischen Signalen, welche Datenbits darstellen, durch die Prozessoreinheit 21, was zu einer Umwandlung oder Reduzierung der elektrischen Signaldarstellung führt, und die Unterhaltung von Datenbits an Speicherstellen in dem Speichersystem (z. B. in dem Systemspeicher 22, in dem Festplattenlaufwerk 27, auf den Disketten 29 und CD-ROM 31), um dadurch den Betrieb des Computersystems neu zu konfigurieren oder auf andere Weise zu verändern, ebenso wie eine andere Verarbeitung von Signalen umfassen. Bei den Speicherstellen, wo Datenbits unterhalten werden, handelt es sich um physische Stellen, welche spezielle elektrische, magnetische oder optische Eigenschaften aufweisen, die den Datenbits entsprechen.
  • Überblick über das MTS-Programmierungsmodell
  • 2 zeigt eine Serveranwendungs-Ausführungsumgebung 82 des Microsoft Transaction Server (MTS), in welcher ein erfindungsgemäßes kompensierendes Ressourcenmanagement enthalten ist. Die MTS-Ausführungsumgebung 82 ist in den oben angeführten einbezogenen MTS-Patentanmeldungen detaillierter beschrieben.
  • Bezug nehmend nun auf 2, stellt ein Transaktionsserver-Hauptsteuerprogramm 80 Laufzeit- oder Systemdienste bereit, um die Laufzeit-Ausführungsumgebung 80 zu erzeugen, welche die Online-Transaktionsverarbeitung durch Serveranwendungskomponenten (z. B. die Serveranwendungskomponente 86) auf einem Server-Computer 84 unterstützt. Das Transaktionsserver-Hauptsteuerprogramm 80 stellt den Serveranwendungskomponenten 86 auch Dienste für das Teilprozess- und Kontextmanagement bereit. Außerdem stellt das Transaktionsserver-Hauptsteuerprogramm 80 systemdefinierte Objekte (z. B. ein Komponentenkontextobjekt 136) bereit, welche Komponentenintegrations-Schnittstellen unterstützen. Das dargestellte Transaktionsserver-Hauptsteuerprogramm 80 ist als dynamische Bibliothek (Dynamic Link Library, „DLL") realisiert. (Eine DLL ist ein wohlbekanntes ausführbares Dateiformat, welches eine dynamische oder Laufzeitverknüpfung eines ausführbaren Codes mit einem Prozess eines Anwendungsprogramms ermöglicht.) Das Transaktionsserver-Hauptsteuerprogramm 80 wird direkt in Prozesse eines Anwendungsservers (z. B. Application Server Process, „ASP" 90) geladen, welche für Serveranwendungskomponenten die Hostfunktion ausüben, und läuft transparent im Hintergrund dieser Prozesse ab.
  • Bei dem dargestellten ASP 90 handelt es sich um einen Systemprozeß, welcher für die Ausführung von Serveranwendungskomponenten die Hostfunktion ausübt. Jeder ASP 90 kann für mehrere Serveranwendungskomponenten die Hostfunktion ausüben, welche zu einer Zusammenstellung gruppiert sind, die als „Paket" bezeichnet wird. Auch können mehrere ASP 90 unter einem vielfädigen Mehrprogramm-Betriebssystem (in der dargestellten Ausführungsform z. B. Microsoft Windows NT) auf dem Server-Computer ablaufen. Jeder ASP 90 stellt eine separate Vertrauensgrenze und Fehlerisolierungsdomäne für die Serveranwendungskomponenten bereit. Wenn sie in getrennten ASP ablaufen, beeinträchtigt mit anderen Worten im Allgemeinen ein Fehler einer Serveranwendungskomponente, welcher bewirkt, daß ihr ASP beendet wird, nicht die Serveranwendungskomponenten in einem anderen ASP. In der dargestellten Ausführungsform sind die Serveranwendungskomponenten zu einem Paket gruppiert, um unter Anwendung eines Verwaltungsdienstprogramms, welches als „COM Explorer" bezeichnet wird, zusammen in einem ASP 90 abzulaufen. Dieses Dienstprogramm stellt eine graphische Benutzerschnittstelle zum Verwalten von Attributen bereit, die zu Serveranwendungskomponenten gehören, umfassend das Gruppieren der Komponenten zu Paketen.
  • In einer typischen Installation, welche in 2 dargestellt ist, befindet sich die Ausführungsumgebung 80 auf dem Server-Computer 84 (welcher ein Beispiel für den oben beschriebenen Computer 20 sein kann), welcher in einem dezentralen Computernetzwerk verbunden ist, welches eine große Anzahl von Client-Computern 92 umfaßt, welche auf die Serveranwendungskomponenten in der Ausführungsumgebung zugreifen. Alternativ kann sich die Ausführungsumgebung 80 auf einem einzelnen Computer befinden, und Host-ServerAnwendungskomponenten, auf welche von Client-Prozessen zugegriffen wird, residieren ebenfalls auf diesem Computer.
  • Die Serveranwendungskomponenten 86, für welche die Ausführungsumgebung 80 des ASP 90 die Hostfunktion ausübt, realisieren die Geschäftslogik einer Serveranwendung, z. B. den Code für die Verwaltung von Kurseinschreibungen in der Einschreibungsanwendung einer Universität oder von Aufträgen in einer Online-Verkaufsanwendung. Typischerweise umfasst jede Serveranwendung mehrere Komponenten, von denen jede Programmcode für einen Teil der Aufgaben einer Anwendung enthält. Zum Beispiel kann eine Bankanwendung eine Transferkomponente, eine Kontobelastungskomponente und eine Kontogutschriftkomponente umfassen, welche Teile der Aufgaben einer Geldtransferoperation der Anwendung durchführen. Die Kontobelastungskomponente in diesem Bankanwendungsbeispiel realisiert einen Programmcode dafür, ein bestimmtes Konto in einer Bankdatenbank mit einer bestimmten Summe zu belasten. Die Kontogutschriftkomponente realisiert einen Programmcode dafür, einem bestimmten Konto in der Datenbank eine Summe gutzuschreiben. Die Transferkomponente realisiert einen Programmcode, welcher die Kontobelastungskomponente und die Kontogutschriftkomponente verwendet, um einen Geldtransfer zwischen zwei Konten zu bewirken.
  • Die Serveranwendungskomponente 86 in der dargestellten Ausführungsform entspricht dem Component Object Model („COM") der Spezifikationen OLE und ActiveX der Microsoft Corporation (wird also als „COM Object" realisiert), kann aber alternativ auch gemäß anderen Objektstandards realisiert werden, z. B. gemäß der CORBA-Spezifikation (Common Object Request Broker Architecture) der Object Management Group. Die OLE-COM-Spezifikation definiert Binärstandards für Komponenten und ihre Schnittstellen, welche die Integration von Software-Komponenten erleichtern. Aus Konvention sind die Schnittstellen eines COM-Objekts graphisch als Steckerbuchse dargestellt, wie für die Serveranwendungskomponente 86 in 2 dargestellt. Auch werden den Schnittstellen üblicher Weise Namen gegeben, die mit einem großen „I” beginnen. Für eine detaillierte Beschreibung von OLE wird auf Kraig Brockschmidt, Inside OLE, Zweite Auflage, Microsoft Press, Redmond, Washington, 1995, verwiesen.
  • In der Ausführungsumgebung 80 der 2 wird die Serveranwendungskomponente 86 unter der Steuerung des Transaktionsserver-Hauptsteuerprogramms 80 im ASP 90 ausgeführt. Das Transaktionsserver-Hauptsteuerprogramm 80 ist für das Laden der Serveranwendung DLL 300 in das ASP 90 und das Instanzieren der Serveranwendungskomponente 86 unter Verwendung der Klassenfabrik 122 verantwortlich. Das Transaktionsserver-Hauptsteuerprogramm 80 verwaltet ferner Aufrufe der Serveranwendungskomponente 86 von Client-Programmen (welche sich entweder auf demselben Computer befinden, oder über eine Netzwerkverbindung).
  • Die dargestellte Ausführungsumgebung 80 stellt an die Serveranwendungskomponente 86 bestimmte zusätzliche Anforderungen, außer daß sie den COM-Anforderungen entsprechen muß. Erstens wird die Serveranwendungskomponente in einer DLL-Datei (also der Serveranwendungs-DLL 120 der 3) realisiert. (COM-Objekte können ansonsten alternativ in einer ausführbaren Datei ("exe"-Datei) realisiert werden.) Zweitens weist die DLL-Datei 120 der Komponente eine Standard-Klassenfabrik 122 auf (d. h., die DLL realisiert und exportiert die DIlGetClassObject-Methode und unterstützt die IClassFactory-Schnittstelle). Drittens exportiert die Serveranwendungskomponente nur Schnittstellen, welche standardmäßig zusammengestellt werden können, was bedeutet, daß die Schnittstellen der Komponenten entweder durch eine Typbibliothek beschrieben werden oder eine Proxy-Programmstumpf-DLL aufweisen. Die Proxy-Programmstumpf-DLL stellt eine Proxy-Komponente 130 in einem Client-Prozess 132 auf dem Client-Computer 92 und eine Pro grammstumpfkomponente 131 in dem ASP 90 auf dem Server-Computer 84 bereit. Die Proxy-Komponente 130 und die Programmstumpfkomponente 131 stellen Aufrufe von einem Client-Programm 134 über den Server-Computer 84 hinweg zusammen. Die Proxy-Programmstumpf-DLL in dem dargestellten System wird unter Anwendung der MIDL-Version 3.00.44 gebildet, welche mit Microsoft Win32 SDK für Microsoft Windows NT 4.0 mit dem Oicf-Kompilierer-Schalter bereitgestellt wird, und wird mit dem Transaktionsserver-Hauptsteuerprogramm 80 verbunden. Diese zusätzlichen Anforderungen entsprechen wohlbekannten Praktiken.
  • Das Client-Programm 134 der Serveranwendungskomponente 86 ist ein Programm, welches die Serveranwendungskomponente verwendet. Bei dem Client-Programm kann es sich um einen Programmcode (z. B. ein Anwendungsprogramm, COM-Objekt usw.) handeln, welcher außerhalb der Ausführungsumgebung 80 abläuft (nicht unter der Steuerung des Transaktionsserver-Hauptsteuerprogramms 80). Solche Client-Programme werden als „Basis-Clients" bezeichnet.
  • Alternativ kann es sich bei dem Client-Programm 134 um eine andere Serveranwendungskomponente handeln, welche auch unter der Steuerung des Transaktionsserver-Hauptsteuerprogramm 80 abläuft (entweder in demselben oder einem eigenen ASP 90). Das Client-Programm 134 kann sich auf dem Server-Computer 84 oder auf einem eigenen Client-Computer 92 befinden, wie in 2 dargestellt (in diesem Fall wirkt der Client-Computer mit der Serveranwendungskomponente 86 aus der Entfernung über das Proxy-Objekt 130 und das Programmstumpf-Objekt 131 zusammen).
  • Der Server-Computer 84 führt auch einen Ressourcenmanager 140 und einen Ressourcendispenser 144 aus. Der Ressourcenmanager 140 ist ein Systemdienst, welcher dauerhafte Daten (z. B. Daten in einer Datenbank 146) verwaltet. Die Serveranwendungskomponente 86 kann den Ressourcenmanager verwenden, um den dauerhaften Zustand der Serveranwendung (z. B. das Verzeichnis des verfügbaren Inventars, zu bearbeitender Aufträge und verfügbarer Konten in einer Online-Verkaufs-Serveranwendung) aufrecht zu erhalten. Beispiele für Ressourcenmanager in der dargestellten Ausführungsform sind der Microsoft SQL Server, dauerhafte Meldungswarteschlangen und Transaktion-Dateisysteme. Vorzugsweise unterstützt der Ressourcenmanager 140 die Durchführung von Veränderungen oder Aktualisierungen des dauerhaften Zustands der Serveranwendung durch die Serveranwendungskomponente 86 auf Transaktionsbasis (also in Transaktionen, welche den wohlbekannten ACID-Eigenschaften entsprechen).
  • Der Ressourcendispenser 144 ist ein Dienst, welcher einen nicht dauerhaften gemeinsamen Zustand (also ohne die Garantie der Dauerhaftigkeit) für die Serveranwendungskomponenten innerhalb des ASP 90 verwaltet. Ressourcendispenser sind in der dargestellten Ausführungsumgebung auch für die automatische Transaktionsteilnahme verantwortlich, wie in den oben angeführten einbezogenen MTS-Patentanmeldungen beschrieben. Beispiele für den Ressourcendispenser 144 in der dargestellten Ausführungsform sind ein ODBC-Ressourcendispenser, welcher einen Pool von Datenbankverbindungen unterhält, die der Aufrufebenen-Schnittstelle Microsoft Open Database Connectivity („ODBC") entsprechen. Der ODBC-Ressourcendispenser weist der Serveranwendungskomponente Datenbankverbindungen für den Zugriff auf Daten aus einer Datenbank 146 (im Allgemeinen über ihren Ressourcenmanager 140) zu. Außerdem verlangt der ODBC-Ressourcendispenser Datenbankverbindungen zurück, wenn sie von den Serveranwendungskomponenten für eine spätere Neuverwendung freigegeben werden.
  • Die dargestellte Ausführungsumgebung 82 umfasst ferner einen Transaktionsmanager 148. Der Transaktionsmanager 148 ist ein Systemdienst, welcher Transaktionen koordiniert, die mehrere Ressourcenmanager überspannen, einschließlich solcher, wobei sich die Ressourcenmanager in einem dezentralen Netzwerk auf mehr als einem Server-Computer befinden. Der Transaktionsmanager 148 stellt sicher, daß Aktualisierungen ungeachtet von Fehlern (z. B. Computer- oder Netzwerk-Hardware- oder Software-Fehlern oder Fehlern, die von einem sich fehlerhaft verhaltenden Ressourcenmanager oder einer fehlerhaften Anwendung verursacht werden), Konkurrenzzuständen (z. B. eine Transaktion, welche beginnt abgeschlossen zu werden, während ein Ressourcenmanager einen Abbruch initiiert) oder Verfügbarkeit (ein Ressourcenmanager bereitet eine Transaktion vor, kehrt aber nie zurück) über alle an einer Transaktion teilnehmenden Ressourcenmanager hinweg gemäß den ACID-Eigenschaften geschehen, wobei das wohlbekannte Zweiphasen-Abschlussprotokoll verwendet wird. Der dargestellte Transaktionsmanager 148 ist der Microsoft Distributed Transaction Coordinator (MSDTC), welcher als Teil des Microsoft SQL Servers 6.5 ausgegeben wird.
  • Die Architektur des kompensierenden Ressourcenmanagers
  • Bezug nehmend nun auf 3 umfasst eine komponenten- oder objektbasierte Architektur 200 eines kompensierenden Ressourcenmanagers (CRM) eine Anzahl von vom System bereitgestellten Komponenten und von systemdefinierten Schnittstellen, welche es den Entwicklern ermöglichen, Ressourcen mit dauerhafter Datenspeicherung schneller und einfacher in die MTS-Ausführungsumgebung 82 (2) zu integrieren, ohne daß sie einen vollständigen Ressourcenmanager und Ressourcendispenser speziell für die Ressource realisieren müssen (z. B. den Ressourcenmanager 140 und den Ressourcendispenser 144 der 2). Die dargestellte Architektur 200 ist insbesondere für zwei Ressourcenszenarios anwendbar, namentlich (1) ein Alt- oder Blackbox-Transaktionsverarbeitungssystem, welches seinen eigenen internen Mechanismus aufweist, um Transaktionen zu behandeln, aber nicht die OLE-Transaktionsschnittstellen unterstützt, und (2) Ressourcen ohne Transaktionsunterstützung. Die Architektur 200 ermöglicht in dem ersteren Szenario eine einfachere Integration in die MTS-Umgebung 82 (2), indem eine Ressourcenmanager-Infrastruktur mit Unterstützung der OLE-Transaktionsschnittstellen bereitgestellt wird und die Notwendigkeit beseitigt wird, einen Ressourcendispenser für den Ressourcenmanager zu haben. Ferner ermöglicht die Architektur 200 in jedem Szenario, daß die Ressourcen durch die Anwendung des erfindungsgemäßen kompensierenden Ressourcenmana gements mit einem einfacheren, einfacher zu entwickelnden Ressourcenmanager integriert werden.
  • In der dargestellten Architektur 200 eines kompensierenden Ressourcenmanagers muß der Entwickler nur ein CRM-Arbeitsprogramm 202 und einen CRM-Kompensator 206 realisieren, welche die vom System bereitgestellten Komponenten und Schnittstellen der Architektur 200 benutzen, um für ein kompensierendes Ressourcenmanagement der Ressource zu sorgen. Das CRM-Arbeitsprogramm 202 und der CRM-Kompensator 206 sind typischerweise in einem MTS-Bibliothekspaket installiert, so daß sie in jedem MTS-Serverprozess (z. B. ASP 90) benutzt werden können.
  • Im CRM-Arbeitsprogramm 202 realisiert der Entwickler eine Logik (also einen Programmcode) speziell für die Ressource, um an der Ressource eine normale Aktion als Teil einer Transaktion durchzuführen. Der Entwickler realisiert auch eine ressourcenspezifische Schnittstelle (z. B. die „IDoWork"-Schnittstelle 210), an welche eine Serveranwendungskomponente 86 Aufrufe ausgeben kann, um zu bewirken, daß das CRM-Arbeitsprogramm 202 die normale Aktion an der Ressource durchführt. Das CRM-Arbeitsprogramm 202 bewirkt die normale Aktion an der Ressource zum Zeitpunkt der Anforderung der Serveranwendungskomponente, so daß die Ergebnisse der normalen Aktion unmittelbar nach der Anforderung auf der Ressource persistent sind.
  • Andererseits realisiert der Entwickler eine Logik im CRM-Kompensator 206, welche für kompensierende Aktionen sorgt, die auf die normale Aktion des CRM-Arbeitsprogramms 202 bezogen sind. Der Entwickler realisiert ferner den CRM-Kompensator 206, um eine systemdefinierte Schnittstelle (die „ICompensatingResourceManager"-Schnittstelle 212) zu unterstützen, über welche der CRM-Kompensator vom Transaktionsmanager 148 (2) Vorbereitungs-, Abschluss- und Abbruchsnotifikationen empfangt. Diese Notifikationen vom Transaktionsmanager werden dem CRM-Kompensator mittels einer vom System bereitgestellten Infrastruktur, einer Wiederherstellungsmaschine und eines unten beschriebenen CRM-Clerks zugeführt. Während der Vorbereitungsphase einer Transaktion, in welcher das CRM-Arbeitsprogramm 202 seine normale Aktion durchgeführt hat, kann der CRM-Kompensator in Reaktion auf die Vorbereitungsnotifikation bewirken, daß die Transaktion abgebrochen wird, z. B. wenn die Umstände eine erfolgreiche Beendigung der Transaktion verhindern würden. In der zweiten Phase der Transaktion kann der CRM-Kompensator auf eine Abschlussnotifikation reagieren, indem er für die normale Aktion des CRM-Arbeitsprogramms an der Ressource die richtigen Reinigungsaktionen durchführt. Alternativ kann der CRM-Kompensator auf eine Abbruchsnotifikation reagieren, indem er eine kompensierende Aktion durchführt, welche die normale Aktion des CRM-Arbeitsprogramms umkehrt.
  • Die normalen, die Reinigungs- und die kompensierenden Aktionen variieren im Allgemeinen in Abhängigkeit von der speziellen dauerhaften Ressource, die verwaltet wird. Wo es sich bei der Ressource zum Beispiel um ein Dateisystem oder eine Datenbank handelt, können die Aktionen Datenverarbeitungsaktivitäten umfassen, z. B. das Modifizieren von Daten, das Schreiben neuer Daten oder das Löschen von Daten aus der Ressource. In dem Fall einiger Ressourcen können die Reimgungs- und/oder kompensierenden Aktionen des CRM-Kompensators zusätzlich zu der Datenverarbeitung Aktivitäten wie die Ausgabe von Bargeld, Tickets oder anderen Gegenständen aus einem Geldausgabegerät oder einer anderen automatisierten Ausgabemaschine umfassen, welche irreversible Ergebnisse in der echten Welt aufweisen können (eine solche Operation, welche irreversible Folgen in der physischen Welt aufweist, wird hierin als „reale Operation" bezeichnet).
  • Weitere Komponenten der CRM-Architektur 200 sind in die MTS-Laufzeitumgebung und Dienste integriert und sind somit „vom System bereitgestellt". Dies ermöglicht dem Entwickler, nur das CRM-Arbeitsprogramm und den CRM-Kompensator zu realisieren, welche für eine bestimmte Ressource spezifisch sind, und sich auf diese vom System bereitgestellten Komponenten zu verlassen, um Dienste bereitzustellen, welche sich mit Problemen wie Logging, Wiederherstellung und Teilprozesssicherheit befassen. Die vom System bereitgestellten Komponenten der dargestellten Architektur 200 umfassen einen CRM-Clerk 222, einen CRM-Wiederherstellungs-Clerk 224 und ein persistentes Log 226. Jede von diesen ist ebenfalls als COM-Komponente realisiert. Alle dieser Komponenten laufen innerhalb des Anwendungsserverprozesses (ASP) 90 (ebenfalls in 2 dargestellt) ab.
  • Die CRM-Architektur 200 sorgt dadurch für Teilprozesssicherheit, daß die vom System bereitgestellten Komponenten der Architektur individuell teilprozesssicher sind, was bedeutet, daß sie von jedem Teilprozess aus aufgerufen werden können. Ferner unterstützt die CRM-Architektur 200 alle der OLE-Transaktionsschnittstellen, die benötigt werden, um mit MTS verbunden zu werden. Die CRM-Architektur 200 geht nicht davon aus, daß die Benutzer der Funktionalität der Architektur (also die Serveranwendungskomponenten 86) selbst teilprozesssicher sind. Die CRM-Architektur 200 garantiert, daß alle Aufrufe des CRM-Kompensators in demselben Apartment vorgenommen werden, in welchem der CRM-Kompensator gemäß Standard-COM-Programmierungspraktiken erzeugt wurde. Mit anderen Worten geht die CRM-Architektur davon aus, daß ihre Benutzer wenigstens Apartmentmodellkomponenten sind (ein wohlbekanntes Teilprozessmodell).
  • Der CRM-Clerk 222 und der CRM-Wiederherstellungs-Clerk 224 stellen Logging- und Wiederherstellungsdienste in der Architektur 200 bereit. Während des normalen Betriebs erzeugt jedes CRM-Arbeitsprogramm 202 seine eigene Instanz eines CRM-Clerks (es besteht also ein Eins-zu-Eins-Verhältnis zwischen CRM-Arbeitsprogramm und CRM-Clerk). Das CRM-Arbeitsprogramm 202 greift auf den CRM-Clerk 222 über eine systemdefinierte Schnittstelle, die ICrmLogControl-Schnittstelle 230, zu, um Informationen in die Warteschlange zu stellen, welche in das persistente Log 226 geloggt werden sollen. Der CRM-Clerk fügt den Log-Aufzeichnungen weitere Informationen hinzu, bevor sie in das Log geschrieben werden. Während der normalen Verarbeitung ist der CRM-Clerk 222 auch für das Instanzieren des CRM-Kompensators und das Weiterleiten von Zweiphasen-Abschlussnotifikationen zu dem CRM-Kompensator, wie erforderlich, verantwortlich.
  • Der CRM-Wiederherstellungs-Clerk 224 arbeitet als Log- und Wiederherstellungsmanager, welcher allen kompensierenden Ressourcenmanagern in dem Computersystem gemeinsam zusteht. Der CRM-Wiederherstellungs-Clerk 224 ist eine Einermengen-COM-Komponente, was bedeutet, daß es immer nur eine Instanz des CRM-Wiederherstellungs-Clerk in dem ASP 90 gibt. Der CRM-Wiederherstellungs-Clerk 224 führt die ursprüngliche Wiederherstellung auf dem persistenten Log 226 durch, welche automatisch initiiert wird, wenn der MTS-Serverprozess (z. B. ASP 90), welcher für die CRM-Komponenten die Hostfunktion ausübt, anläuft. Danach bleibt der CRM-Wiederherstellungs-Clerk 224 aktiv, um Fixpunkte auf dem Log zu initiieren, und um einen zentralen Punkt bereitzustellen, durch welchen CRM-Clerks überwacht werden.
  • Der CRM-Wiederherstellungs-Clerk 224 unterstützt eine „ICrmMonitor"-Schnittstelle 234, welche erhalten wird, indem die „CoCreatelnstance()"-API-Methode mit der CLSID des CRM-Wiederherstellungs-Clerks aufgerufen wird. Die „ICrmMonitor"-Schnittstelle ist in der Programmauflistung 320 definiert, welche in 18 dargestellt ist. Die „ICrmMonitor"-Schnittstelle 234 wird verwendet, um zu überwachen, welche Transaktionen für die CRMs im ASP 90 aktuell ablaufen (z. B. durch eine Programm- oder COM-Komponente, welche Benutzeranzeigen oder Dialoge für eine Operator- oder Administratorperson bereitstellt). Die von dem CRM-Arbeitsprogramm bei der Registrierung des CRM-Kompensators (siehe die unten beschriebene „RegisterCompensator()"-Methode) bereitgestellten Textbeschreibungen sind verfügbar, um bei der Suche nach einer bestimmten CRM-Aktivität zu helfen.
  • Die „ICrmMonitor"-Schnittstelle bietet eine Methode („GetClerks()"), um einen Schnittstellenzeiger auf eine „ICrmMonitorClerks"-Schnittstelle auf einem Clerk-Zusammenstellungsobjekt zu erhalten, welcher die CRM-Clerks 222 der Architektur 200 eines kompensierenden Ressourcenmanagers verfolgt. Die „ICrmMonitorClerks"-Schnittstelle ist in der Programmauflistung 319 definiert, welche in 17 dargestellt ist. Über diese Schnittstelle kann ein Zeiger auf eine „ICrmMonitorLogRecords"-Schnittstelle erhalten werden, welche auf dem CRM-Clerk 222 unterstützt wird. Die „ICrmMonitorLogRecords"-Schnittstelle wird verwendet, um die einzelnen Log-Aufzeichnungen zu überwachen, welche von einem speziellen CRM-Clerk für eine gegebene Transaktion unterhalten werden, z. B. für die unten beschriebene Wiederherstellung durch Menschen. Die „ICrmMonitorLogRecords"-Schnittstelle ist in der Programmauflistung 318 definiert, welche in 16 dargestellt ist.
  • Jeder ASP 90, welcher den CRM verwendet, weist sein eigenes zugehöriges persistentes Log 226 auf, um Log-Aufzeichnungen zu speichern. Das persistente Log 226 in der dargestellten CRM-Architektur 200 ist eine Log-Datei des TXF-Formats, welche einen Dateinamen besitzt, der auf der zu dem ASP 90 gehörigen AppId basiert. Wenn er (in Reaktion auf die unten beschriebene „ForceLog()"-Methode) Log-Aufzeichnungen schreibt, schreibt der CRM-Clerk 222 Log-Aufzeichnungen in einer laufenden Reihenfolge in das persistente Log 226. Der CRM-Wiederherstellungs-Clerk 224 initiiert ebenfalls periodisch Fixpunkte in dem persistenten Log 226, um Platz von Log-Aufzeichnungen zurückzugewinnen, der nach beendeten Transaktionen freigesetzt wurde.
  • Das CRM-Arbeitsprogramm 202 loggt (über den CRM-Clerk 222 und den CRM-Wiederherstellungs-Clerk 224, wie gerade beschrieben) ausreichende Informationen in das persistente Log 226, typischerweise, allerdings nicht notwendigerweise, auf einer Vorabeintragungs-Basis, wenn es für die Serveranwendungskomponente 86 seine normale Aktion an der Ressource durchführt, so daß die CRM-Architektur 200 bewirken kann, daß der CRM-Kompensator 206 in Reaktion auf die Zweiphasen-Abschluss-Protokollnotifikationen geeignete Aktionen unternimmt (z. B. eine Abstimmaktion während der Vorbereitung, eine Reinigungsaktion nach einem Abschluss oder eine kompensierende Aktion nach einem Abbruch). Das CRM-Arbeitsprogramm 202 registriert auch eine Klassenkennung („CLSID") des CRM-Kompensators 206 mit dem CRM-Clerk 222. Später, wenn die Transaktion vorbei ist (was in der MTS-Umgebung typischerweise in Reaktion auf einen SetComplete- oder SetAbort-Aufruf von der (den) Serveranwendungskomponente(n) 86 in der Transaktion der Fall ist, wie in den obigen einbezogenen MTS-Patentanmeldungen beschrieben), erzeugt der CRM-Clerk 222 den CRM-Kompensator 206 und ruft für jede der Zweiphasen-Abschlussnotifikationen, welche es vom Transaktionsmanager 148 empfangt (2), an seiner ICrmCompensator- (oder ICrmCompensatorVariants-)Schnittstelle geeignete Methoden auf. Mit den Zweiphasen-Abschlussnotifikationen stellt der CRM-Clerk 222 individuell für die Transaktion die vom CRM-Arbeitsprogramm 202 geschriebenen Log-Aufzeichnungen zu – in Vorwärtsreihenfolge für den Abschluss und in Rückwärtsreihenfolge für den Abbruch, um innerhalb der Transaktion die Reihenfolge der Aktionen zu bewahren. Der CRM-Kompensator 206 kann auch Informationen über seine eigenen kompensierenden Aktionen in das persistente Log loggen, welche während der Wiederherstellung benötigt werden können. Das CRM-Arbeitsprogramm 202 und der CRM-Kompensator 206 teilen daher einen Zustand nur durch das persistente Log 226.
  • Das persistente Log 226 ist in der dargestellten Architektur 200 als ein Log-Objekt 240, eine Wiederherstellungsmaschine 240 und eine Log-Datei 244 realisiert. Bei dem Log-Objekt handelt es sich um ein COM-Objekt, welches einen seriellen Strom von Log-Aufzeichnungen verkapselt und dafür verantwortlich ist, einen sequenziellen Strom von Log-Aufzeichnungen stabil in die Log-Datei 244 zu schreiben. Das Log-Objekt 240 stellt Methoden zum Schreiben und Lesen der Log-Aufzeichnungen aus der Log-Datei 244 über eine „ILog"-Schnittstelle 246 bereit, welche vom CRM-Clerk 222, vom CRM-Wiederherstellungs-Clerk 224 und von der Wiederherstellungsmaschine 242 angewendet werden.
  • Bei der Log-Datei 244 handelt es sich um einen seriellen Datenstrom, welcher in einem nichtflüchtigen Speicher (z. B. auf dem Festplattenlaufwerk der 1) gespeichert ist, z. B. um eine Datei oder Zusammenstellung von Dateien eines Dateisystems, in welchem Log-Aufzeichnungen gespeichert werden. Bei der dargestellten Log-Datei 244 handelt es sich um eine Datei, welche das Microsoft-TXF-Dateiformat aufweist. Jede Log-Aufzeichnung in der dargestellten Log-Datei 244 ist durch eine Log-Sequenznummer (LSN) gekennzeichnet, bei welchen es sich im seriellen Strom um monoton steigende 64-Bit-Ganzzahlen handelt. Für jeden ASP 90 wird auf dem Computer 20 (1) eine separate Log-Datei bewahrt. In der dargestellten Architektur 200 ist die Log-Datei 244 durch einen Dateinamen gekennzeichnet, welcher auf einer einzigartigen Kennung basiert, die zu dem entsprechenden ASP 90 (z. B. zu der „AppId" im Betriebssystem Microsoft Windows NT) gehört, und befindet sich auf demselben Dateisystempfad wie ein Log des Transaktionsmanagers 148. Dies erleichtert die Wiederherstellung basierend auf dem Log.
  • Bei der Wiederherstellungsmaschine 242 handelt es sich um ein COM-Objekt, welches Dienste über eine „ILogRecover"-Schnittstelle 248 und eine „ILogRecoverClerkRegistration"-Schnittstelle bereitstellt, um die Log-Aufzeichnungen aus der Log-Datei 244 nach einem Systemneustart gemäß einem Log-Wiederherstellungsprotokoll zu verarbeiten, um eine Wiederherstellung nach Fehlern zu bewirken. Die in der dargestellten Wiederherstellungsmaschine 242 realisierte Wiederherstellungsverarbeitung basiert auf dem wohlbekannten Log-Wiederherstellungsprotokoll ARIES, obwohl stattdessen auch ein anderes Log-Wiederherstellungsprotokoll oder eine Abweichung davon verwendet werden kann. (Es wird verwiesen auf C. Mohan, D. Haderle, B. Lindsay, H. Pirahesh und P. Schwarz, ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write Ahead Logging, in Readings in Database Systems, Zweite Auflage (Hrsg. Michael Stonebraker 1994).) Der CRM-Wiederherstellungs-Clerk 224 und der CRM-Clerk 222 registrieren sich bei der Wiederherstellungsmaschine 242, so daß Log-Aufzeichnungen, welche von diesen Einheiten geschrieben werden, von der Wiederherstellungsmaschine 242 während der Wiederherstellung bereitgestellt werden können. Die Wiederherstellungsmaschine 242 nimmt mit dem Transaktionsmanager 148 (2) auch an der Transaktion teil, an welcher das CRM-Arbeitsprogramm 202 und der CRM-Clerk 222 teilnehmen. Während des normalen Betriebs in der Architektur 200 empfangt die Wiederherstellungsmaschine 242 die Zweiphasen-Abschlussnotifikationen vom Transaktionsmanager 148 und leitet die Notifikationen zusammen mit Log-Aufzeichnungen, welche die Transaktion betreffen, an den CRM-Clerk 222 weiter, welcher auf die Notifikationen reagiert, indem er den CRM-Kompensator 206 erzeugt und die richtigen kompensierenden Aktionen durch den CRM-Kompensator 206 initiiert. Die Wiederherstellungsmaschine 242 nimmt mit dem Transaktionsmanager 148 an Transaktionen teil und empfängt Zweiphasen-Abschlussnotifikationen vom Transaktionsmanager unter Verwendung der OLE-Transaktionsschnittstellen. Der CRM-Clerk 222 und der CRM-Wiederherstellungs-Clerk 224 realisieren eine Gruppe von Schnittstellen (umfassend die Schnittstellen „ILogRecoverClerk", „ILogRecoverClerkRecordsOnTerminate" und „ILogRecoverClerkPhaseNotificati on"), auf welchen die Clerks die Zweiphasen-Abschlussnotifikationen von der Wiederherstellungsmaschine 242 empfangen.
  • Betriebssequenz
  • 4 zeigt eine Reihenfolge der Ausführung der Komponenten innerhalb der dargestellten CRM-Architektur 200. Anfänglich erzeugt die Serveranwendungskomponente 86 das CRM-Arbeitsprogramm 202 unter Verwendung einer herkömmlichen COM-Objekt-Instanzierungsmethodik, wie in Schritt 251 angezeigt. In einem Fall, in dem die Serveranwendungskomponente 86 eine Transaktion aufweist, assoziiert die MTS-Ausführungsumgebung 82 automatisch das CRM-Arbeitsprogramm 202 in dieser Transaktion, wie in „Automatic Transaction Processing Of Component-Based Server Applications", US-Patentanmeldung 08/959,141 (durch Bezugnahme oben hierin einbezogen) beschrieben.
  • In einem nächsten Schritt 252 erzeugt das CRM-Arbeitsprogramm 202 eine Instanz des CRM-Clerks 222 und erhält einen Schnittstellenverweis auf die ICrmLogControl-Schnittstelle 230 des CRM-Clerks 222, indem es die „CreateInstance()"-Methode (eine wohlbekannte Anwendungsprogrammierungs-Schnittstellen(API)-Methode in der COM-Laufzeitdienste-Bibliothek, welche für die Objektinstanzierung verwendet wird) aufruft und die CLSID des CRM-Clerks und die IID der ICrmLogControl-Schnittstelle spezifiziert. Hierdurch wird auch automatisch die CRM-Clerk-Instanz in der Transaktion assoziiert.
  • Nach dem Erhalt des ICrmLogControl-Schnittstellenverweises ruft das CRM-Arbeitsprogramm 202 eine „RegisterCompensator()"-Methode der Schnittstelle auf, um das CRM-Kompensator-Gegenstück 206 für das CRM-Arbeitsprogramm 202 bei dem CRM-Clerk 222 zu registrieren, wie in Schritt 253 gezeigt. Das CRM-Arbeitsprogramm 202 registriert den CRM-Kompensator 206 durch eine Kennung seiner Klasse (z. B. eine Programmkennung (PROGID) oder eine Klassenkennung (CLSID)), welche unter COM für den CRM-Clerk 222 eine ausreichende Identifikation darstellt, um später den CRM-Kompensator 206 zu erzeugen.
  • Außerdem registriert der CRM-Clerk 222 sich selbst bei dem CRM-Wiederherstellungs-Clerk 224 und der Wiederherstellungsmaschine 242 unter Verwendung einer global einzigartigen Kennung (GUID), welche zu der speziellen Instanz der CRM-Clerk-Klasse gehört. Der CRM-Wiederherstellungs-Clerk 224 loggt alle aktiven CRM-Clerks in dem Log 226 ein, um später bei der Wiederherstellung die Neuerzeugung des CRM-Clerks zu ermöglichen. Wenn der CRM-Clerk bei der Wiederherstellungsmaschine 242 registriert ist, nimmt die Wiederherstellungsmaschine 242 mit dem Transaktionsmanager 148 an der Transaktion der Serveranwendungskomponente teil. Dies ermöglicht der Wiederherstellungsmaschine 242, Zweiphasen-Abschlussnotifikationen zu empfangen, welche bei der Transaktion vom Transaktionsmanager ausgegeben werden, und die Notifikationen an den CRM-Clerk 222 weiterzuleiten.
  • In einem nächsten Schritt 254 fordert die Serveranwendungskomponente 86 an, daß das CRM-Arbeitsprogramm 202 als Teil seiner Transaktion einen Arbeitsvorgang an der Ressource durchführt. Wenn das CRM-Arbeitsprogramm 202 den angeforderte Arbeitsvorgang (also seine normale Aktion) durchführt, loggt das CRM-Arbeitsprogramm zuerst in Schritt 255 unter Verwendung des CRM-Clerks 222 ausreichende Informationen in das persistente Log 226, damit der CRM-Kompensator 206 die geeigneten Reinigungs- und Kompensierungsaktionen vornehmen kann. Wie unten erläutert, schreibt das CRM-Arbeitsprogramm 202 eine Sequenz von Log-Aufzeichnungen in den CRM-Clerk 222 (unter Anwendung der „WriteLogRecord()"- oder „WriteLogRecordVariants()"-Methode) und bewirkt dann (unter Anwendung der „ForceLog()"-Methode), daß die Aufzeichnungen auf der Vorabeintragungsbasis in das persistente Log herausgeschrieben werden, bevor der angeforderte Arbeitsvorgang durchgeführt wird.
  • Später gibt der Transaktionsmanager 148 in Schritt 256 Zweiphasen-Abschlussprotokollnotifikationen an die Teilnehmer der Transaktion (also die an der Transaktion teilnehmenden Komponenten) aus, z. B. an die Wiederherstellungsmaschine 242, welche die Notifikationen zusammen mit den zuvor vom CRM-Arbeitsprogramm 202 geschriebenen Log-Aufzeichnungen an den CRM-Clerk 222 weiterleitet. Typischerweise werden diese Notifikationen gesendet, nachdem die Serveranwendungskomponente 86, welche die Transaktion initiiert hat, SetComplete aufgerufen hat, um anzuzeigen, daß alle Arbeitsvorgänge der Transaktion abgeschlossen sind, oder eine Komponente in der Transaktion SetAbort aufruft, wodurch angezeigt wird, daß der Arbeitsvorgang nicht erfolgreich abgeschlossen werden kann. Set-Complete und SetAbort sind Schnittstellenmethoden des vom System bereitgestellten Kontextobjekts 136 (2) und sind detaillierter in den obigen einbezogenen MTS-Patentanmeldungen beschrieben. Der Transaktionsmanager 148 gibt die Zweiphasen-Abschlussprotokollnotifikationen auf der ITransactionResourceAsync-Schnittstelle 238 (welche ein Teil der OLE-Transaktionsschnittstellen ist) an die Wiederherstellungsmaschine 242 aus.
  • In Reaktion auf jede Zweiphasen-Abschlussprotokollnotifikation erzeugt der CRM-Clerk 222 in Schritt 257 den CRM-Kompensator 206, der zuvor von dem CRM-Arbeitsprogramm 202 bei dem CRM-Clerk 222 registriert wurde. In Schritt 258 ruft der CRM-Clerk 222 dann eine geeignete Methode der ICrmCompensator-Schnittstelle 212 auf, um die Notifikation und die zugehörigen Log-Aufzeichnungen zum CRM-Kompensator 206 weiterzuleiten. Mit seinem Aufruf an den CRM-Kompensator 206 leitet der CRM-Clerk 222 einen Schnittstellenzeiger für die ICrmLogControl-Schnittstelle 230 weiter, um dem CRM-Kompensator zu ermöglichen, Log-Aufzeichnungen seiner kompensierenden Aktionen zu schreiben.
  • In Schritt 259 führt der CRM-Kompensator 206 die für die Zweiphasen-Abschlussnotifikation richtige Abstimmungs-, Reinigungs- oder Kompensierungsaktion durch, basierend auf den vom CRM-Arbeitsprogramm 202 geloggten Informationen. Wenn angebracht, kann der CRM-Kompensator 206 auch Informationen über seine Reinigungs- oder Kompensierungsaktionen für die Verwendung während der Wiederherstellung loggen.
  • Logging
  • 5 zeigt ein Verfahren 280, durch welches das CRM-Arbeitsprogramm 202 Informationen dafür loggt, seine normale Aktion an der Ressource zu kompensieren. In der dargestellten Architektur 200 (3) werden Informationen in einer Hinterher-Speicherform in das Log geschrieben. Das CRM-Arbeitsprogramm 202 verwendet die ICrmLogControl-Schnittstelle 230 des CRM-Clerks, um Log-Aufzeichnungen in Warteschlange zu stellen, welche eine von dem CRM-Arbeitsprogramm 202 vorgenommene Aktion repräsentieren, welche dann zusammen zur permanenten Speicherung in der Log-Datei 244 gebracht werden. Das CRM-Arbeitsprogramm 202 führt das Logging vorzugsweise auf einer Vorabeintragungsbasis durch, bevor es irgendwelche Aktionen an der Ressource durchführt, welche später eine Kompensation erforderlich machen können.
  • Als Anfangsschritt 281 des Logging-Verfahrens 280 bildet das CRM-Arbeitsprogramm 202 eine Log-Aufzeichnung als Zusammenstellung von Datenelementen. In der dargestellten Architektur 200 kann die Log-Aufzeichnung strukturiert oder unstrukturiert sein. Eine strukturierte Log-Aufzeichnung ist eine Zusammenstellung von Datenelementen des Variant-Typs, wie z. B. ein Visual-Basic-Zusammenstellungsobjekt. Unstrukturierte Log-Aufzeichnungen sind einfach ein Puffer aus Bytes. Typischerweise schreibt ein CRM-Arbeitsprogramm, welches in der Program miersprache Microsoft Visual Basic geschrieben ist, strukturierte Log-Aufzeichnungen, während eines, das in den Programmiersprachen Microsoft Visual C++ oder J++ geschrieben ist, unstrukturierte Log-Aufzeichnungen schreibt. Das CRM-Arbeitsprogramm 202 in der dargestellten Architektur eines kompensierenden Ressourcenmanagers 200 darf nicht strukturierte und unstrukturierte Log-Aufzeichnungen vermischen und muß Log-Aufzeichnungen nur eines dieser Typen schreiben.
  • Wenn die Log-Aufzeichnung gebildet ist, ruft das CRM-Arbeitsprogramm 202 in Schritt 282 eine „WriteLogRecord()"-Methode (oder „WriteLogRecordVariants()"-Methode für strukturierte Log-Aufzeichnungen) auf der ICrmLogControl-Schnittstelle 230 des CRM-Clerks 222 auf, um die Log-Aufzeichnung in eine Warteschlange zu kopieren. Wie in Schritt 283 angezeigt, kann das CRM-Arbeitsprogramm die Schritte 281 bis 282 mehrere Male wiederholen, um mehrere Log-Aufzeichnungen in Warteschlange zu stellen.
  • Nachdem das CRM-Arbeitsprogramm 202 für die Aktion, welche das CRM-Arbeitsprogramm 202 an der Ressource vornehmen möchte, alle Log-Aufzeichnungen in Warteschlange gestellt hat, ruft das CRM-Arbeitsprogramm 202 in Schritt 284 auf der ICrmLogControl-Schnittstelle 230 des CRM-Clerks 222 die „ForceLog()"-Methode auf, um zu bewirken, daß die in der Warteschlange stehenden Log-Aufzeichnungen in das persistente Log 226 ausgeschrieben werden. Die separaten „WriteLogRecord()"- und „ForceLog()"-Methoden ermöglichen dem CRM-Arbeitsprogramm 202 somit, mehrere Log-Aufzeichnungen in Warteschlange zu stellen und zusammen in das persistente Log 226 schreiben zu lassen, was die Logging-Effizienz verbessert.
  • Bei der Realisierung der „WriteLogRecord()"-, „WriteLogRecordVariants()"- und „Force-Log()"-Methode im CRM-Clerk 222 wird die ILog-Schnittstelle 246 des Log-Objekts verwendet, um geschriebene Log-Aufzeichnungen in Cache-Form zu speichern und dann in die Log-Datei 244 zu bringen.
  • Fixpunkte
  • Bezug nehmend wiederum auf 3, verwendet das persistente Log 226 Fixpunkte, um in der Log-Datei 244 Raum von Log-Aufzeichnungen aus abgeschlossenen Transaktionen zurückzugewinnen.
  • Der CRM-Wiederherstellungs-Clerk 224 gibt periodisch anfängliche Fixpunktanforderungen an die Wiederherstellungsmaschine 242 aus, indem er auf der ILogRecover-Schnittstelle 248 die „TakeCheckpoint()"-Methode aufruft. Der CRM-Wiederherstellungs-Clerk 224 weist einen Hintergrund-Teilprozess auf, welcher auf Ereignisse oder einen Zeitablauf wartet. Bei Zeitablauf überprüft der CRM-Wiederherstellungs-Clerk 224, ob seit dem letzten Fixpunkt irgendwelche Log-Aufzeichnungen geschrieben worden sind. Wenn nicht, wird keine Fixpunktanforderung initiiert. Diese periodischen Fixpunktanforderungen ermöglichen der Wiederherstellungsmaschine, die Log-Datei 244 automatisch neu zu dimensionieren oder zu vergrößern, wenn sie für die Transaktionsgeschwindigkeit und das Volumen der Log-Aufzeichnungen nicht ausreicht.
  • Der CRM-Wiederherstellungs-Clerk 224 überprüft auch, ob es aktuell irgendwelche CRM-Clerks 222 gibt, bevor er eine Fixpunktanforderung initiiert. Wenn es keine gibt, wird keine Fixpunktanforderung initiiert. Wenn es aktuell CRM-Clerks gibt, loggt der CRM-Wiederherstellungs-Clerk 224 die Clerk-Instanzkennungen der CRM-Clerks, so daß die CRM-Clerks während der Wiederherstellungsverarbeitung richtig erzeugt werden können. Der CRM-Wiederherstellungs-Clerk 224 loggt eine einzige Log-Aufzeichnung, die „Clerk-Listen-Aufzeichnung", welche die Clerk-Instanzkennungen aller aktuellen CRM-Clerks enthält.
  • Der CRM-Wiederherstellungs-Clerk 224 leitet ferner die Trunkierung des Log. Während der Fixpunktverarbeitung durch die Wiederherstellungsmaschine 242 lässt die Wiederherstellungsmaschine 242 (unter Anwendung der „ILogRecoverClerk::WriteCheckpoint()"-Methode) den CRM-Wiederherstellungs-Clerk 224 und jeden CRM-Clerk 222 Fixpunkt-Log-Aufzeichnungen schreiben und die minimale für ihre Log-Aufzeichnungen verwendete LSN zurücksenden. Der CRM-Wiederherstellungs-Clerk 224 schreibt vor der Ausgabe der Fixpunktanforderung an die Wiederherstellungsmaschine die Clerk-Listen-Log-Aufzeichnung, sendet dann die LSN der Clerk-Listen-Log-Aufzeichnung als seine minimale LSN aus der Fixpunkt-Schreibanforderung der Wiederherstellungsmaschine zurück. Hierdurch wird garantiert, daß die Clerk-Listen-Aufzeichnung vor jeglichen Fixpunktaufzeichnungen der CRM-Clerks 222 in der Log-Datei 244 geschieht, und daß die letzten beiden Fixpunkte in der Log-Datei 244 behalten werden.
  • In Reaktion auf die Fixpunkt-Schreibanforderungen der Wiederherstellungsmaschine an die CRM-Clerks kopiert jeder CRM-Clerk 222 seine Log-Aufzeichnungen auf Basis eines jeden anderen Fixpunkts weiter. Insbesondere, wenn der CRM-Clerk 222 das erste Mal mit einer Fixpunkt-Schreibanforderung aufgerufen wird und eine laufende Transaktion aufweist, sendet der CRM-Clerk 222 seine minimale in Gebrauch befindliche LSN zurück. Das nächste Mal kopiert der CRM-Clerk 222 alle seine Log-Aufzeichnungen weiter und sendet seine neue minimale LSN zurück. Beim Weiterkopieren liest der CRM-Clerk 222 alle Log-Aufzeichnungen, welche er in die Log-Datei 244 geschrieben hat, und schreibt die Log-Aufzeichnungen neu in die Log-Datei 244. Dieser Ansatz bedeutet, daß nur die letzten beiden Fixpunkte in der Log-Datei 244 behalten werden, während die Frequenz, mit welcher der CRM-Clerk 222 seine Log-Aufzeichnungen weiterkopieren muß, verringert wird. Das persistente Log 226 kann dann so gepackt werden, daß freigesetzter Raum aus abgeschlossenen Transaktionen neu verwendet wird. Vorzugsweise ist das Zeitablaufintervall der anfänglichen Fixpunktanforderungen des CRM-Wiederherstellungs-Clerks 224 so eingestellt, daß die meisten der Transaktionen innerhalb von zwei Fixpunkten abgeschlossen werden und ein Weiterkopieren für den CRM-Clerk 222 normalerweise nicht erforderlich ist.
  • Der CRM-Clerk 222 beginnt das Schreiben eines Fixpunkts mit einer Fixpunktstartaufzeichnung und endet mit einer Fixpunktendaufzeichnung. Dies ermöglicht, daß die Grenzen des Fixpunkts während der Wiederherstellung genau identifiziert werden, und daß bestimmt wird, ob der Fixpunkt erfolgreich abgeschlossen wurde oder durch einen Fehler unterbrochen wurde. Der CRM-Clerk 222 fügt ferner jeder Log-Aufzeichnung, die er schreibt, eine Sequenznummer hinzu, und fügt Log-Aufzeichnungen, die in einen Fixpunkt weiterkopiert werden, Kopiermerker hinzu. Wenn Vergessensaufzeichnungen (welche eine vorige Log-Aufzeichnung identifizieren, die vergessen werden soll) weiterkopiert werden, aktualisiert der CRM-Clerk 222 die Vergessensaufzeichnung, um die vergessene Log-Aufzeichnung anhand ihrer neuen (weiterkopierten) LSN richtig zu identifizieren.
  • Während der Fixpunktverarbeitung blockiert der CRM-Clerk 222 neue Log-Aufzeichnungs-Schreibvorgänge vom CRM-Arbeitsprogramm 202 oder CRM-Kompensator 206, um die Reihenfolge der über den CRM-Clerk geschriebenen Log-Aufzeichnungen aufrecht zu erhalten. Auch Zweiphasen-Abschlussnotifikationen werden blockiert, während ein Fixpunkt in Bearbeitung ist. Fixpunktanforderungen werden während normaler Schreibvorgänge in das persistente Log 226 und während der Verarbeitung von Transaktionsabschlussnotifikationen in ähnlicher Weise blockiert.
  • Kompensierung
  • In der dargestellten CRM-Architektur 200 der 3 stellt der Transaktionsmanager 148 ( 2) für den kompensierenden Ressourcenmanager die Zweiphasen-Abschlussnotifikationen über die ITransactionResourceAsync-Schnittstelle 238 der Wiederherstellungsmaschine 242 (welche während der Registrierung des CRM-Clerks 222 bei der Wiederherstellungsmaschine an der Transaktion teilnahm) bereit. Für jede Notifikation liest die Wiederherstellungsmaschine 242 alle Log-Aufzeichnungen aus, welche in Verbindung mit der Clerk-Instanzkennung des CRM-Clerks 222 in das Log geschrieben worden sind (was die Log-Aufzeichnungen umfaßt, die vom CRM-Arbeitsprogramm 202 für seine normale Aktion geschrieben worden sind). Die Wiederherstellungsmaschine 242 leitet dann unter Verwendung der (unten beschriebenen) ILogRecoverClerkPhaseNotification-Schnittstelle des CRM-Clerks die Notifikation und die Log-Aufzeichnungen an den CRM-Clerk 222 weiter.
  • Der CRM-Clerk 222 reagiert auf die Aufrufe der Wiederherstellungsmaschine, indem er unter Verwendung der mit dem CRM-Ressourcendispenser 220 registrierten CLSID den CRM-Kompensator 206 erzeugt. Der CRM-Clerk 222 ruft dann eine Methode der ICrmCompensator-Schnittstelle 212 (im Fall unstrukturierter Log-Aufzeichnungen) oder der ICrmCompensatorVariants-Schnittstelle 212 (im Fall strukturierter Log-Aufzeichnungen) auf dem CRM-Kompensator 206 auf, welche für die entsprechende Zweiphasen-Abschlussnotifikation die richtige ist (z. B. BeginPrepare(), PrepareRecord() und EndPrepare() für die Vorbereitungsphasennotifikation). Der CRM-Clerk 222 leitet außerdem in einem Aufruf der „SetLogControl"-Methode auf der ICrmCompensator-Schnittstelle (oder der ICrmCompensatorVariants-Schnittstelle) 212 des CRM-Kompensators 206 einen Zeiger auf seine ICrmLogControl-Schnittstelle weiter, welchen der CRM-Kompensator verwendet, um seine kompensierende Aktion zu loggen.
  • Die Realisierung der Zweiphasen-Abschlussnotifikations-Methoden im CRM-Kompensator 206 führt zur Durchführung der richtigen Aktionen speziell für die Ressource für die durch das CRM-Arbeitsprogramm geloggte Aktion. (Wie oben angemerkt, sorgt für die Realisierung des CRM-Kompensators der Entwickler, z. B. ein Systemintegrator oder anderer Programmierer des kompensierenden Ressourcenmanagers für eine bestimmte Ressource.) In den Vorbereitungsnotifikationsmethoden (also „BeginPrepare()", „PrepareRecord()" und „EndPrepare()") ermittelt der CRM-Kompensator 206, ob der in der Transaktion an der Ressource durchgeführte Arbeits vorgang richtig vorbereitet ist, um abgeschlossen zu werden. In dem Fall der meisten Realisierungen des CRM-Kompensators ist der Arbeitsvorgang des CRM-Arbeitsprogramms 202 in der Transaktion bereits zu der Zeit auf der Ressource persistent gemacht worden, zu der er vom CRM-Arbeitsprogramm durchgeführt wurde. Der CRM-Kompensator kann deswegen so realisiert werden, daß er einfach den „bOkToPrepare"-Parameter der „EndPrepare()"-Methode auf „VARIANT-TRUE" stellt und zurückmeldet. In anderen Verwirklichungen kann der CRM-Kompensator 206 Überprüfungen durchführen, um zu ermitteln, ob der Arbeitsvorgang persistent gemacht oder kompensiert werden sollte, und den „bOkToPrepare"-Parameter dementsprechend einstellen. Zum Beispiel kann durch die Überprüfung ermittelt werden, ob der vom CRM-Arbeitsprogramm durchgeführte Arbeitsvorgang richtig oder widerspruchsfrei ist.
  • Für die Abschlussnotifikationen (z. B. die „BeginCommit()"-, „CommitRecord()" und „End-Commit()"-Methode) kann der CRM-Kompensator 206 irgendwelche Reinigungsaktionen durchführen, um den Arbeitsvorgang des CRM-Arbeitsprogramms an der Ressource abzuschließen. Wo es sich bei der Ressource zum Beispiel um ein Dateisystem handelt und der kompensierende Ressourcenmanager innerhalb einer Transaktion die Fähigkeit bereitstellt, Dateien zu löschen, kann es die normale Aktion des CRM-Arbeitsprogramms sein, die zu löschende Datei umzubenennen oder zu verstecken, so daß die Datei nach einem Abbruch der Transaktion wiederhergestellt werden kann. Der CRM-Kompensator führt in diesem Beispiel eine Reinigungsaktion durch, durch welche die umbenannte oder gelöschte Datei nach einem Abschluss der Transaktion tatsächlich gelöscht wird. Der CRM-Kompensator empfangt die Log-Aufzeichnungen der Aktion des CRM-Arbeitsprogramms (über die „CommitRecord()"-Methode), z. B. den Namen der umbenannten oder versteckten Datei zu lesen. DerCRM-Kompensator verwendet auch die ICrmLogControl-Schnittstelle des CRM-Clerks 222, um die Reinigungsaktionen für Wiederherstellungszwecke zu loggen. Der CRM-Kompensator schreibt die Log-Informationen, nachdem er die Reinigungsaktion durchgeführt hat, um sicherzustellen, daß die Reinigungsaktion vorgenommen worden ist. In dem obigen Beispiel des kompensierenden Ressourcenmanagers für die Dateilöschung loggt der CRM-Kompensator 206 zum Beispiel ein, daß die umbenannte oder versteckte Datei gelöscht worden ist, nachdem die Datei gelöscht worden ist. Wenn dann während der Abschlussphase der Transaktion ein Fehler auftritt, kann die Reinigungsaktion während der darauf folgenden Wiederherstellung ausgelassen werden. Die in der „EndCommit()"-Methode realisierte Reinigungsaktion sollte idempotent sein, so daß sie mehrfach versucht werden kann, mit denselben Ergebnissen, als wenn sie beim ersten Versuch erfolgreich wäre, wie z. B. in einem Fall, in dem ein Fehler auftritt, nachdem der CRM- Kompensator die Reinigungsaktion durchführt, aber bevor eingeloggt wird, daß die Reinigungsaktion durchgeführt wurde, oder wenn Fehler während der Wiederherstellung auftreten.
  • In den Abbruchnotifikationsmethoden führt der CRM-Kompensator 206 eine idempotente kompensierende Aktion durch, um den Arbeitsvorgang des CRM-Arbeitsprogramms 202 umzukehren, welcher typischerweise bereits auf der Ressource persistent gemacht ist. Der CRM-Kompensator empfängt die vom CRM-Arbeitsprogramm geloggten Informationen mit der „AbortRecord()"-Methode. Der CRM-Kompensator loggt auch die kompensierende Aktion mit dem CRM-Clerk 222 auf einer Danacheintragungsbasis. In dem obigen Beispiel des kompensierenden Ressourcenmanagers für die Dateilöschung kann der CRM-Kompensator zum Beispiel realisiert werden, um die umbenannte oder versteckte Datei in der „EndAbort()"-Methode wiederherzustellen.
  • Nachdem der CRM-Kompensator erfolgreich die Verarbeitung seiner kompensierenden Aktionen für die Abschluss- oder Abbruchnotifikation abschließt, schreibt der CRM-Clerk 222 eine Clerk-Beendigungs-Log-Aufzeichnung in das persistente Log 226, um anzuzeigen, daß die Verarbeitung durchgeführt ist und der CRM-Clerk 222 freigegeben werden kann. Der CRM-Clerk 222 benachrichtigt auch den CRM-Wiederherstellungs-Clerk 224, so daß er von der Liste der aktuell registrierten CRM-Clerks entfernt werden kann.
  • Wiederherstellung
  • In der dargestellten CRM-Architektur 200, die in 3 dargestellt ist, führt die vom System bereitgestellte Infrastruktur (z. B. der CRM-Wiederherstellungs-Clerk 224 und die Wiederherstellungsmaschine 242) auch eine Wiederherstellung durch, nachdem ein Fehler auftritt, welcher die normale Verarbeitung unterbricht. Die Wiederherstellung wird nach dem Anlaufen des ASP 90 (2) initiiert. Während der Anlaufverarbeitung des ASP 90 wird die CRM-Architektur 200 in den ASP geladen, und der CRM-Wiederherstellungs-Clerk 224 wird erzeugt. Beim Anlaufen sucht der CRM-Wiederherstellungs-Clerk 224 nach der Log-Datei 244, welche zu dem ASP gehört. Wie oben beschrieben, weist die Log-Datei 244 einen Dateinamen basierend auf einer Kennung (der AppId) des ASP auf und befindet sich auf demselben Dateisystempfad wie eine Log-Datei des Transaktionsmanagers 148 (2). Wenn die Log-Datei 244 für den ASP existiert, initiiert der CRM-Wiederherstellungs-Clerk auf der Log-Datei 244 die Wiederher stellung (z. B. durch Erzeugen der Wiederherstellungsmaschine 242 und Aufrufen der „ILogRecover::Recover()"-Methode der Wiederherstellungsmaschine).
  • Die Wiederherstellungsmaschine 242 realisiert die Wiederherstellungsverarbeitung gemäß dem ARIES-Wiederherstellungsprotokoll und führt jeden Clerk, welcher bei der Wiederherstellungsmaschine registriert wurde (z. B. den CRM-Wiederherstellungs-Clerk 224 und jeden CRM-Clerk 222), durch Analyse-, Wiederholungs- und Rückgängigmachphasen der Wiederherstellungsverarbeitung (wobei sie die ILogRecoverClerk-Schnittstelle verwendet, welche auf dem CRM-Wiederherstellungs-Clerk 224 und jedem CRM-Clerk 222 realisiert ist). Während der normalen Verarbeitung loggt der CRM-Wiederherstellungs-Clerk 224 Clerk-Listen-Log-Aufzeichnungen (vor den Fixpunkten) und Neu-Clerk-Log-Aufzeichnungen (wenn zwischen Fixpunkten ein neuer Clerk erzeugt wird). Aufgrund der Weise, wie der CRM-Wiederherstellungs-Clerk diese Aufzeichnungen loggt, gehen die Clerk-Listen- und Neu-Clerk-Aufzeichnungen, welche den CRM-Clerk 222 identifizieren, allen Aufzeichnungen voran, die durch einen solchen CRM-Clerk in der Log-Datei 244 geloggt wurden (haben also niedrigere LSNs als diese). Während der Wiederherstellung bewirkt die Wiederherstellungsmaschine deswegen, daß der CRM-Wiederherstellungs-Clerk 224 die Wiederherstellungsverarbeitung der Aufzeichnungen, die den CRM-Clerk 222 identifizieren, durchführt, bevor bewirkt wird, daß der CRM-Clerk 222 die Wiederherstellungsverarbeitung der Log-Aufzeichnungen durchführt, welche der CRM-Clerk geschrieben hat. Wenn er in der Analysephase der Wiederherstellung die Clerk-Listen- und Neu-Clerk-Aufzeichnungen verarbeitet, erzeugt der CRM-Wiederherstellungs-Clerk 224 einen neuen CRM-Clerk für jede in den Aufzeichnungen identifizierte Clerk-Instanzkennung und weist ihm die entsprechende Clerk-Instanzkennung zu. Der erzeugte CRM-Clerk identifiziert sich selbst der Wiederherstellungsmaschine 242 mit der zugewiesenen Clerk-Instanzkennung und ist dann dafür verfügbar, die mit dieser Clerk-Instanzkennung geloggten Log-Aufzeichnungen von der Wiederherstellungsmaschine zu empfangen. Der CRM-Clerk 222 ist dann dafür verantwortlich, die Log-Aufzeichnungen richtig zu interpretieren, den registrierten CRM-Kompensator 206 zu erzeugen und auf dem CRM-Kompensator gemäß dem Ergebnis der Transaktion die richtigen Methoden aufzurufen.
  • In der Analysephase leitet die Wiederherstellungsmaschine 242 alle Log-Aufzeichnungen, welche zu der Clerk-Instanzkennung des CRM-Clerks 222 gehören, (über die „ILogRecoverClerk::AnalyzeRecord()"-Methode) an den CRM-Clerk weiter. Der CRM-Clerk analysiert die Log-Aufzeichnungen, um die richtige Wiederherstellungsverarbeitung durchzuführen. Zuerst sucht der CRM-Clerk nach einer Clerk-Beendigungs-Aufzeichnung. Der CRM-Clerk loggt eine Clerk-Beendigungs-Aufzeichnung während der normalen Verarbeitung nur nach der kompensierenden Aktion des CRM-Kompensators auf eine Abschluss- oder Abbruchnotifikation ein. Wenn eine Clerk-Beendigungs-Aufzeichnung erkannt wird, schließt der CRM-Clerk 222 daraus, daß die Transaktion erfolgreich abgeschlossen wurde (einschließlich der kompensierenden Aktionen des CRM-Kompensators 206) und für diese Instanz des CRM-Clerks keine Wiederherstellung notwendig ist.
  • Wenn keine Clerk-Beendigungs-Aufzeichnung erkannt wird, geht der CRM-Clerk 222 dazu über, eine richtige Sequenz der ursprünglich vom CRM-Clerk geschriebenen Log-Aufzeichnungen zu identifizieren. Der CRM-Clerk 222 kann vor dem Fehler durch mehrere Fixpunkte hindurch überlebt haben, was zu doppelten Kopien einiger Log-Aufzeichnungen mit alten LSNs führt. Der CRM-Clerk 222 ordnet die Log-Aufzeichnungen, die er von der Wiederherstellungsmaschine 242 empfängt, nach ihrer LSN. Der CRM-Clerk 222 verarbeitet die Log-Aufzeichnungen, um sicherzustellen, daß unter einer gegebenen Sequenznummer nur eine Aufzeichnung existiert. Alle Duplikate werden verworfen. Außerdem verarbeitet der CRM-Clerk 222 die Liste für Vergessens-Log-Aufzeichnungen und markiert die Log-Aufzeichnungen, die vergessen werden sollen. Die resultierende Liste ist die richtige Log-Aufzeichnungssequenz für den CRM-Clerk 222.
  • Während dieser Analysephase sucht der CRM-Clerk 222 auch nach einer Clerk-Startaufzeichnung, in welcher der CRM-Clerk die Klassenkennung des CRM-Kompensators geloggt hat, welche vom CRM-Arbeitsprogramm 202 registriert wurde. Am Ende seiner Analysephase sendet der CRM-Clerk 222 die niedrigste LSN in der identifizierten Log-Aufzeichnungssequenz an die Wiederherstellungsmaschine 242 zurück.
  • Nach der Analysephase führt die Wiederherstellungsmaschine 242 ferner den CRM-Wiederherstellungs-Clerk 224 und jeden CRM-Clerk 222 durch Wiederholungs- und Rückgängigmachphasen (über die „BeginRedoPass()"-, „RedoRecord()"-, „BeginUndoPass()"- und „UndoRecord()"-Methode der ILogRecoverClerk-Schnittstelle) und stellt dem CRM-Clerk Notifikationen über den Status der Transaktion des CRM-Clerks zu (über die IRecoverClerkPhaseNotification-Schnittstelle). Der CRM-Wiederherstellungs-Clerk 224 und der CRM-Clerk 222 ignorieren die Wiederholungs- und Rückgängigmachphasen der Wiederherstellung. Die Wiederherstellungsmaschine 242 ermittelt den Transaktionsstatus aus Log-Aufzeichnungen, welche sie während der normalen Verarbeitung geloggt hat, oder durch erneute Teilnahme an der Transaktion mit dem Transaktionsmanager 148 (2).
  • Wenn die Wiederherstellungsmaschine 242 eine für die Transaktion geloggte Vorbereitungsaufzeichnung findet, stellt die Wiederherstellungsmaschine dem CRM-Clerk 222 eine Vorbereitungsnotifikation zu, welcher die Transaktion während der Wiederherstellung aufweist (über die „OnPrepare()"-Methode der IRecoverClerkPhaseNotification-Schnittstelle). Da jedoch die Vorbereitung für den CRM-Kompensator während der Wiederherstellung nicht bedeutsam ist, leitet der CRM-Clerk 222 die Vorbereitungsnotifikation nicht an den CRM-Kompensator weiter.
  • Nach der Ermittlung, daß die Transaktion abgeschlossen oder abgebrochen wurde, stellt die Wiederherstellungsmaschine 242 dem CRM-Clerk 222 die richtige Notifikation zu, welcher die Transaktion während der Wiederherstellung aufweist (über die „OnCommit()"-Methode oder „OnAbort()"-Methode der IRecoverClerkPhaseNotification-Schnittstelle). Wie während der normalen Verarbeitung reagiert der CRM-Clerk 222 auf diese Notifikationen, indem er den CRM-Kompensator erzeugt und dem CRM-Kompensator die Abschluss- oder Abbruchnotifikation zusammen mit den Log-Aufzeichnungen zustellt, die vom CRM-Arbeitsprogramm geschrieben wurden (über die „BeginCommit()"-, „CommitRecord()"-, „EndCommit()"-, „Begin-Abort()"-, „AbortRecord()"- und „EndAbort()"-Methode der ICrmCompensator-Schnittstelle 212). Dies bewirkt, daß der CRM-Kompensator basierend auf den Log-Aufzeichnungen die richtige Reinigungsaktion (für einen Abschluss) oder kompensierende Aktion (für einen Abbruch) durchführt. Nachdem der CRM-Kompensator diese Verarbeitung erfolgreich beendet, schreibt der CRM-Clerk 222 eine Clerk-Beendigungs-Aufzeichnung, um anzuzeigen, daß diese Verarbeitung vorgenommen wurde, und der CRM-Clerk kann freigegeben werden. Der CRM-Clerk 222 benachrichtigt auch den CRM-Wiederherstellungs-Clerk 224, damit er von der Liste der registrierten CRM-Clerks entfernt werden kann.
  • Wenn die Wiederherstellungsmaschine 242 nach der erneuten Teilnahme an der Transaktion mit dem Transaktionsmanager 148 (2) ermittelt, daß über die Transaktion Zweifel bestehen, benachrichtigt die Wiederherstellungsmaschine den CRM-Clerk 222, welcher die Transaktion aufweist, darüber (über die „OnInDoubt()"-Methode der ILogRecoverClerk-Schnittstelle). In diesem Fall ist der CRM-Clerk dafür verantwortlich, seine Log-Aufzeichnungen durch alle folgenden Fixpunkte hindurch in der Log-Datei 244 zu bewahren.
  • Am Ende der Wiederherstellung benachrichtigt die Wiederherstellungsmaschine 242 den CRM-Wiederherstellungs-Clerk 224 und den CRM-Clerk 222, daß die Wiederherstellung beendet ist (über die „EndRecovery()"-Methode der ILogRecoverClerk-Schnittstelle). Wenn seine Transaktion während der Wiederherstellung beendet wurde, wird der CRM-Clerk 222 freigegeben. Der CRM-Wiederherstellungs-Clerk 224 verbleibt nach der Wiederherstellung, um die Liste der registrierten CRM-Clerks zu unterhalten und Fixpunktanforderungen zu initiieren.
  • Kompensierung durch Menschen
  • In einigen mit der CRM-Architektur 200 (3) realisierten kompensierenden Ressourcenmanagern kann der CRM-Kompensator 206 als Teil seiner Reinigungsaktionen und/oder kompensierenden Aktionen eine Kompensierung durch Menschen verwenden.
  • Als Teil des Zweiphasen-Abschlussprotokolls ist es wesentlich, daß der kompensierende Ressourcenmanager die richtigen Aktionen durchführen kann, um die Transaktion abzuschließen oder abzubrechen, nachdem er in der Vorbereitungsphase mit „Ja" gestimmt hat. In kompensierenden Ressourcenmanagern, in welchen eine Kompensierung durch Menschen angewendet wird, ist der CRM-Kompensator in Fällen, in denen die Reinigungsaktion oder die kompensierende Aktion fehlschlägt, auf Aktionen durch Menschen angewiesen. Nach solchen Fehlschlägen stellt der CRM-Kompensator eine Ausgabe bereit, um einen menschlichen Operator darüber zu informieren, eine geeignete manuelle Aktion vorzunehmen, um die Situation zu korrigieren. Der CRM-Kompensator führt dann fort, als ob die Reinigungsaktion oder kompensierende Aktion erfolgreich gewesen wäre, z. B. indem er die richtigen Informationen loggt und als Antwort auf den „EndCommit()"- oder „EndAbort()"-Aufruf „Erfolg" (als HRESULT-Rückmeldewert der Methode) anzeigt. Wenn erforderlich, kann der CRM-Kompensator anfordern, daß der CRM-Clerk 222 die Log-Aufzeichnungen von Beginn an neu abspielt, indem er auf die „CommitRecord()"- oder „AbortRecord"-Aufrufe, durch welche die Log-Aufzeichnungen vom CRM-Clerk zugestellt werden, einen Fehlercode zurücksendet. Dies ermöglicht, daß die vollständige Sequenz der Log-Aufzeichnungen in einer separaten Datei zur Verwendung bei einer späteren Kompensation durch Menschen gespeichert wird, wenn der Fehler, der eine Kompensation durch Menschen erforderlich macht, nach einem Teil der Verarbeitung der Log-Aufzeichnungen durch den CRM-Kompensator auftritt.
  • Die Nachricht an den menschlichen Operator kann in Form einer sichtbaren Bildschirmmeldung, einer akustischen Meldung, eines ausgedruckten Berichts oder einer anderen Meldung vorgenommen werden. Gewöhnlich wird die Nachricht die für die Transaktion relevanten Log-Aufzeichnungen in einem von Menschen lesbaren Format umfassen, um für den menschlichen Operator ausreichende Informationen bereitzustellen, um die erforderliche manuelle Berichtigungsaktion durchzuführen, oder es wird dem menschlichen Operator auf andere Weise ermöglicht, solche Aufzeichnungen zu untersuchen (z. B. indem die Log-Aufzeichnungen in eine separate Datei geschrieben werden, die für den menschlichen Operator unter Verwendung eines Log-Einsichtnahme-Hilfsprogramms einzusehen ist).
  • Zum Beispiel kann ein kompensierender Ressourcenmanager, welcher eine Kreditkartenzahlung bewirkt, als Teil der kompensierenden Aktion für eine Kreditkartenbelastung eine Kompensation durch Menschen anwenden. Wo die Transaktion abgebrochen wurde, ist es die kompensierende Aktion, eine Gutschrift auf das Konto vorzunehmen. Wenn der CRM-Kompensator keine Gutschrift auf das Konto vornehmen kann, z. B. aufgrund der fehlenden Verfügbarkeit eines anderen Computers oder einer Kommunikationsverbindung, die benötigt wird, um auf die Kontoinformationen zuzugreifen, kann der CRM-Kompensator stattdessen die kompensierende Aktion durch menschliches Eingreifen durchführen. Der CRM-Kompensator benachrichtigt den menschlichen Operator, daß eine manuelle Aktion erforderlich ist, und kann für den Operator einen Zugang zu den Log-Aufzeichnungen bereitstellen, damit dieser ermitteln kann, welchem Konto welcher Betrag gutzuschreiben ist.
  • Verschobene Wiederherstellung
  • In einigen kompensierenden Ressourcenmanagern, die mit der CRM-Architektur 200 (3) realisiert sind, kann der CRM-Kompensator 206 als Teil seiner Reinigungs- und/oder kompensierenden Aktion alternativ eine verschobene Wiederherstellung anwenden. Bei verschobener Wiederherstellung bleiben die Log-Aufzeichnungen der normalen Aktionen des CRM-Arbeitsprogramms im persistenten Log 226, wenn die Reinigungs- oder kompensierende Aktion des CRM-Kompensators 206 während der normalen Verarbeitung oder während der Wiederherstellungsverarbeitung fehlschlägt. Der CRM-Kompensator 206 sendet auf die „EndCommit()"- oder „EndAbort()"-Methode ein Fehlerergebnis zurück. Da die Abschluss- oder Abbruchphase nicht beendet wird, existiert die Transaktion weiterhin, und der Transaktionsmanager 148 ( 2) bewahrt die Informationen über die Transaktion. Die CRM-Architektur 200 und die MTS- Ausführungsumgebung 82 fahren jedoch mit der Wiederherstellungsverarbeitung (falls während einer Wiederherstellung) und auch mit der normalen Verarbeitung anderer Transaktionen fort. Bei einer späteren Wiederherstellung bewirkt der CRM-Clerk 222, daß der CRM-Kompensator 206 die verschobene Reinigungsaktion oder kompensierende Aktion erneut versucht.
  • Schnittstellendefinitionen
  • Die ICrmLogControl-Schnittstelle. Bezug nehmend wiederum auf 3, unterstützt der CRM-Clerk 222 die ICrmLogControl-Schnittstelle 230. Die ICrmLogControl-Schnittstelle 230 wird vom CRM-Arbeitsprogramm 202 und möglicherweise auch vom CRM-Kompensator 212 verwendet, um Aufzeichnungen in das persistente Log 226 zu schreiben. Das CRM-Arbeitsprogramm 202 registriert auch 230 sein Gegenstück, den CRM-Kompensator 212, unter Verwendung der ICrmLogControl-Schnittstelle beim CRM-Clerk 222.
  • Die ICrmLogControl-Schnittstelle 230 stellt eine Gruppe von Methoden bereit, wie in der Programmauflistung der 6 dargestellt. Die „TransactionUOW()"-Methode wird vom CRM angewendet, um eine Transaction-Unit-Of-Work-Kennung der Transaktion zu erhalten, in welcher das CRM-Arbeitsprogramm seine normale Aktion durchführt.
  • Wie oben erörtert, ruft das CRM-Arbeitsprogramm 202 die „RegisterCompensator()"-Methode auf, um sein Gegenstück, den CRM-Kompensator 206, beim CRM-Clerk 222 zu registrieren. Das CRM-Arbeitsprogramm 202 ruft die Methode zuerst auf, nachdem es einen Zeiger auf die ICrmLogControl-Schnittstelle erhalten hat (also bevor es die Schnittstelle verwendet, um irgendwelche Log-Aufzeichnungen in das persistente Log zu schreiben), und kann die Methode nur einmal erfolgreich aufrufen (nachfolgende Versuche oder ein Versuch durch den CRM-Kompensator, die Methode aufzurufen, fahren zu einem E_FAIL-Rückmeldewert). Das CRM-Arbeitsprogramm 202 legt eine Klassenkennung (CLSID) oder Programmkennung (PROGID) im Zeichenkettenformat des CRM-Kompensators 206 als „IpcwstrProgIdCompensator"-Parameter des Aufrufs fest. Das CRM-Arbeitsprogramm 202 leitet in dem „IpcwstrDescription"-Parameter auch eine Textbeschreibung weiter, die für eine Überwachung oder Verwaltung verwendet werden kann. Außer der Registrierung des CRM-Arbeitsprogramms führt die Methode auch eine Anzahl von Überprüfungen durch, um sicherzustellen, daß der CRM fortfahren kann. Diese Überprüfungen umfassen das Verifizieren, daß der CRM-Kompensator erzeugt werden kann und mindestens eine der (unten beschriebenen) ICrmCompensator- oder ICrmCompensatorVariants-Schnittstellen unterstützt. Wenn nicht, meldet die Methode entsprechend „E_FAIL"- oder „E-NOINTERFACE"-Werte zurück. Die Methode überprüft ferner, daß der aktuelle Kontext gültige Transaktion- und Aktivitätskennungen aufweist. Schließlich meldet die Methode dann, wenn der CRM-Wiederherstellungs-Clerk die Wiederherstellungsverarbeitung nicht beendet hat oder wenn er schwerwiegende Fehler für den CRM erkannt hat, entsprechend „XACT-E-RECOVERYINPROGRESS"- oder „E-FAIL"-Werte zurück.
  • Die „WriteLogRecordVariants"-Methode wird vom CRM-Arbeitsprogramm 202 und vom CRM-Kompensator 206 aufgerufen, um strukturierte Log-Aufzeichnungen in das Log zu schreiben. Strukturierte Aufzeichnungen sind Aufzeichnungen, die als Zusammenstellung von Werten des Variant-Typs aufgebaut sind. Typischerweise wird diese Methode verwendet, wo das CRM-Arbeitsprogramm und der CRM-Kompensator in Microsoft Visual Basic geschrieben sind und die strukturierte Aufzeichnung ein Visual-Basic-Collection-Objekt ist. Die Methode meldet einen Fehlercode „E_FAIL" zurück, wenn der CRM-Kompensator 206, der von dem CRM-Arbeitsprogramm 202 registriert wurde, nicht die ICrmCompensatorVariants-Schnittstelle unterstützt. Das CRM-Arbeitsprogramm und der CRM-Kompensator dürfen nicht sowohl strukturierte als auch unstrukturierte Log-Aufzeichnungen verwenden. Dementsprechend erhält ein Aufruf dieser Methode nach einem vorhergehenden erfolgreichen Aufruf der „WriteLogRecord()"-Methode einen „E_FAIL"-Wert zurück. Die Methode meldet auch den „E_FAIL"-Wert zurück, wenn sie vom CRM-Arbeitsprogramm 202 aufgerufen wird, nachdem die Transaktion beendet ist oder sich im Beendigungsvorgang befindet. Der CRM-Kompensator kann jedoch die Methode weiter anwenden, um während der Transaktionsergebnisnotifikationen weitere Log-Aufzeichnungen zu schreiben.
  • Die „ForceLog()"-Methode wird vom CRM-Arbeitsprogramm 202 und vom CRM-Kompensator 206 aufgerufen, um zu bewirken, daß Log-Aufzeichnungen, die zuvor unter Anwendung der „WriteLogRecord()"- oder WriteLogRecordVariants()"-Methode geschrieben wurden, in das persistente Log 226 herausgeschrieben werden, welches sich im persistenten Speicher des Computers (z. B. im Festplattenlaufwerk 27 der 1) befindet, wo es einen Fehler übersteht. Wenn die Log-Aufzeichnungen persistent gemacht sind, kann das CRM-Arbeitsprogramm 202 mit seiner normalen Aktion an der Ressource fortfahren.
  • Die „ForgetLogRecord()"-Methode wird vom CRM-Arbeitsprogramm 202 oder vom CRM-Kompensator 206 aufgerufen, um zu bewirken, daß der CRM-Clerk die letzte Log-Aufzeichnung, die (z. B. unter Anwendung der „WriteLogRecord()"- oder „WriteLogRecordVariants()"-Methode) geschrieben wurde, vergißt. In der dargestellten CRM-Architektur 200 kann die Methode nur angewendet werden, um die letzte geschriebene Log-Aufzeichnung zu vergessen, und ermöglicht keine Verschachtelung. Die vergessene Log-Aufzeichnung wird dem CRM-Kompensator während Zweiphasen-Abschlussnotifikationen nicht zugestellt.
  • Das CRM-Arbeitsprogramm 202 ruft die „ForcTransactionToAbort()"-Methode auf, um einseitig zu bewirken, daß die Transaktion unmittelbar abgebrochen wird (z. B. über einen Aufruf der MTS-ITransaction::Abort-Methode, wie in den obigen einbezogenen MTS-Patentanmeldungen detaillierter beschrieben). Ein Aufruf der Methode durch den registrierten CRM-Kompensator 202 erhält einen Fehlercode „E_FAIL" zurück, weil der CRM-Kompensator nicht aktiv ist, solange sich die Transaktion im Beendigungsvorgang befindet.
  • Die „WriteLogRecord()"-Methode wird vom CRM-Arbeitsprogramm 202 und vom CRM-Kompensator 206 aufgerufen, um unstrukturierte Log-Aufzeichnungen zu schreiben (welche typischerweise verwendet werden, wo das CRM-Arbeitsprogramm und der CRM-Kompensator in Microsoft Visual C++ oder Visual J++ geschrieben sind). Bei den unstrukturierten Aufzeichnungen handelt es sich einfach um einen Puffer aus Bytes. Die Methode stellt eine Zusammenstellungsmöglichkeit bereit, indem sie ermöglicht, daß Abschnitte der Log-Aufzeichnung durch das CRM-Arbeitsprogramm (oder den CRM-Kompensator) als Feld solcher Puffer (der „rgBlob"-Parameter) aufgebaut werden, welche dann durch diese Methode in einer einzelnen Operation in einem Puffer kopiert werden, der vom CRM-Clerk unterhalten wird. Die Methode meldet in den folgenden Fällen einen Fehlercode („E_FAIL") zurück: (1) der registrierte CRM-Kompensator unterstützt nicht die ICrmCompensator-Schnittstelle, (2) die Methode wurde nach einem vorhergehenden erfolgreichen Aufruf der „WriteLogVariants()"-Methode aufgerufen (da der CRM-Clerk 222 nicht zuläßt, daß strukturierte und unstrukturierte Aufzeichnungen vermischt werden) und (3) das CRM-Arbeitsprogramm ruft die Methode auf, nachdem die Transaktion beendet ist oder sich im Beendigungsvorgang befindet.
  • Die ICrmCompensator- und ICrmCompensatorVariants-Schnittstellen. Immer noch Bezug nehmend auf 3, unterstützt der CRM-Kompensator 206 eine oder beide aus der ICrmCompensator- und der ICrmCompensatorVariants-Schnittstelle 212. Die Schnittstellen werden vom CRM-Clerk 222 benutzt, um dem CRM-Kompensator Zweiphasen-Abschlussnotifikationen und die vom CRM-Arbeitsprogramm 202 während seiner normalen Aktion geloggten Aufzeichnungen zuzustellen. Wie oben für die ICrmLogControl-Schnittstelle erörtert, müssen die Aufzeichnungen für einen speziellen CRM in Abhängigkeit davon, ob die „WriteLogRecordVariants()"- oder die „WriteLogRecord()"-Methode angewendet wurde, alle entweder strukturiert oder unstrukturiert sein. Die ICrmCompensator-Schnittstelle wird verwendet, um unstrukturierte Log-Aufzeichnungen zuzustellen, während die ICrmCompensatorVariants-Schnittstelle dem CRM-Kompensator strukturierte Log-Aufzeichnungen zustellt.
  • Die ICrmCompensator- und die ICrmCompensatorVariants-Schnittstelle sind in den Programmauflistungen 302 bis 303 definiert, die in 7 und 8 dargestellt sind. Die „SetLogControl()"-Methode wird vom CRM-Clerk 222 zuerst aufgerufen, nachdem er den CRM-Kompensator 212 erzeugt hat, um an den CRM-Kompensator 212 (als „pLogControl"-Parameter) einen Zeiger auf die ICrmLogControl-Schnittstelle 230 des CRM-Clerks 222 weiterzuleiten. Dies ermöglicht dem CRM-Kompensator, während der Beendigung der Transaktion weitere Log-Aufzeichnungen zu schreiben. Ein anderer Rückmeldewert als „S_OK" von dieser Methode wird als Fehler des CRM-Kompensators angesehen, der einen „schnellen Abbruch" des ASP 90 bewirkt, solange er nicht speziell über einen Registermerker für die CLSID des CRM-Kompensators außer Kraft gesetzt ist.
  • Die „BeginPrepare()"-Methode wird vom CRM-Clerk 222 als Vorbereitungsnotifikation (Phase 1 des Zweiphasen-Abschlussprotokolls) an den CRM-Kompensator aufgerufen und zeigt an, daß Log-Aufzeichnungen im Begriff sind, zugestellt zu werden. Die Vorbereitungsnotifikation wird nur während der normalen Verarbeitung und nicht während der Wiederherstellung gesendet. Wiederum wird ein anderer Rückmeldewert als „S_OK" als CRM-Kompensator-Fehler angesehen.
  • Die PrepareRecord()"-Methode wird vom CRM-Clerk 222 aufgerufen, um dem CRM-Kompensator 206 während der Vorbereitungsphase eine Log-Aufzeichnung zuzustellen. Die Log-Aufzeichnungen werden in Vorwärtsreihenfolge zugestellt. Unstrukturierte Log-Aufzeichnungen werden als „CrmLogRecordRead"-Datenstruktur zugestellt, welche ein Merkerfeld („dwCrmFlags"), eine Sequenznummer („dwSequenceNumber") und die Log-Aufzeichnungs-Daten („blobUserData") enthält. Das Merkerfeld und die Sequenznummer stellen Informationen bereit, welche unter Umständen, unter denen eine Kompensierung durch Men schen erforderlich ist, für ein Austesten oder eine Fehleridentifikation nützlich sein können. Das Merkerfeld umfasst Merker, die anzeigen, ob die Aufzeichnung vergessen gemacht wurde und wann die Aufzeichnung geschrieben wurde. Die Sequenznummer der Log-Aufzeichnung zeigt ihre Sequenz im persistenten Log 226 an. Der CRM-Kompensator 206 kann den Vergessensmerker (den „pfForget"-Parameter) auf die Rückmeldung von der Methode stellen, so daß er bewirkt, daß der CRM-Clerk die durch den Methodenaufruf zugestellte Log-Aufzeichnung vergißt. Der CRM-Kompensator 206 kann den Wert „ERROR-REPLAY-RECORDS" zurückmelden, um zu bewirken, daß der CRM-Clerk 222 die Zustellung aller vom CRM-Arbeitsprogramm geschriebenen Log-Aufzeichnungen wiederholt, auch einschließlich jener, die vergessen gemacht wurden, und jener, die vom CRM-Kompensator während der Vorbereitungsphase geschrieben wurden. Ein anderer Rückmeldewert als „S_OK" oder „ERROR-REPLAY-RECORDS" wird als Fehler des CRM-Kompensators angesehen, der einen schnellen Abbruch des ASP 90 bewirkt. Die „PrepareRecordVariants()"-Methode ähnelt der „PrepareRecord()"-Methode, stellt aber strukturierte Log-Aufzeichnungen zu.
  • Die „EndPrepare()"-Methode wird vom CRM-Clerk 222 aufgerufen, um anzuzeigen, daß alle während der Vorbereitungsphase verfügbaren Log-Aufzeichnungen zugestellt worden sind. Wenn keine Log-Aufzeichnungen vom CRM-Arbeitsprogramm 202 geschrieben wurden, lässt der CRM-Clerk zwischen seinen Aufrufen der „BeginPrepare()"- und „EndPrepare()"-Methode den Aufruf der „PrepareRecord()"- oder „PrepareRecordVariants()"-Methode aus. Der CRM-Kompensator stimmt unter Verwendung des „fOkToPrepare"-Parameters über das Transaktionsergebnis ab. Ein anderer Rückmeldewert als „S_OK" wird als CRM-Kompensator-Fehler angesehen, der einen schnellen Abbruch des ASP 90 verursacht.
  • Der CRM-Clerk 222 ruft die „BeginCommit()"- oder „BeginAbort()"-Methode auf, um dem CRM-Kompensator eine Abschluss- bzw. Abbruchnotifikation zuzustellen. Der Aufruf zeigt dem CRM-Kompensator auch an, daß Log-Aufzeichnungen im Begriff sind, für die Verarbeitung der Abschluss- oder Abbruchaktionen durch den CRM-Kompensator 206 zugestellt zu werden. Der „fRecovery"-Parameter ist ein Merker, der anzeigt, ob die Methode während der Wiederherstellung oder der normalen Verarbeitung aufgerufen wird. Ein anderer Rückmeldewert als „S_OK" wird als CRM-Kompensator-Fehler angesehen, der einen schnellen Abbruch des ASP 90 verursacht.
  • Die „CommitRecord()"- und die „AbortRecord()"-Methode werden vom CRM-Clerk 222 aufgerufen, um während der Abschluss- und Abbruchphasenverarbeitung eine unstrukturierte Log-Aufzeichnung zuzustellen. Für strukturierte Log-Aufzeichnungen ruft der CRM-Clerk die ähnliche „CommitRecordVariants()"- oder „AbortRecordVariants()"-Methode auf. Für die „CommitRecord()"-Methode stellt der CRM-Clerk 222 die Log-Aufzeichnungen in Vorwärtsreihenfolge zu. Für die „AbortRecord()"-Methode stellt der CRM-Clerk 222 die Log-Aufzeichnungen in Rückwärtsreihenfolge zu. Wenn keine Log-Aufzeichnungen geschrieben wurden, lässt der CRM-Clerk 222 zwischen „BeginCommit()"- (oder „BeginAbort()"-) und „EndCommit()"- (oder EndAbort()"-) Aufrufen den Aufruf von „CommitRecord()"- (oder „AbortRecord()"-) aus. Der CRM-Kompensator kann den Vergessensmerkerparameter („fForget”) auf Rückmeldung stellen, um zu bewirken, daß der CRM-Clerk die zugestellte Log-Aufzeichnung vergißt. Ein anderer Rückmeldewert als „S_OK" oder „ERROR_REPLAY_RECORDS" wird als CRM-Kompensator-Fehler angesehen, der einen schnellen Abbruch des ASP 90 verursacht.
  • Die „EndCommit()"- und „EndAbort()"-Methode werden vom CRM-Clerk aufgerufen, um den CRM-Kompensator darüber zu benachrichtigen, daß während der Abschluss- oder Abbruchphase alle Log-Aufzeichnungen zugestellt worden sind. Dem CRM-Clerk 222 steht es frei, nach erfolgreicher Beendigung dieser Methode alle Log-Aufzeichnungen für die Transaktion zu verwerfen. Ein anderer Rückmeldewert als „S_OK" wird als CRM-Kompensator-Fehler angesehen, der einen schnellen Abbruch des ASP 90 verursacht.
  • Die ILogRecover-Schnittstelle. Die Wiederherstellungsmaschine 242 unterstützt die ILogRecover-Schnittstelle 248. Die Schnittstelle wird vom CRM-Wiederherstellungs-Clerk 224 benutzt, um während der normalen Verarbeitung Fixpunkte zu initiieren (über einen Aufruf der „Take-Checkpoint()"-Methode), und um während der Wiederherstellungsverarbeitung die Wiederherstellung auf der Log-Datei 244 zu initiieren (über die „Recover()"-Methode). Die ILogRecover-Schnittstelle ist in der Programmauflistung 306 definiert, die in 10 dargestellt ist.
  • Die ILogRecoverClerk-Schnittstelle. Der CRM-Wiederherstellungs-Clerk 224 und jeder CRM-Clerk 222 verwirklichen die ILogRecoverClerk-Schnittstelle. Die Wiederherstellungsmaschine 242 benutzt die ILogRecoverClerk-Schnittstelle, um den CRM-Wiederherstellungs-Clerk 224 und den CRM-Clerk 222 durch Wiederherstellungsphasen zu führen und während der Wiederherstellungsphasen die zu dem Clerk gehörenden Log-Aufzeichnungen zuzustellen. Die Wieder herstellungsmaschine 242 benutzt die ILogRecoverClerk-Schnittstelle auch dafür zu bewirken, daß der CRM-Wiederherstellungs-Clerk 224 und der CRM-Clerk 222 ihre Fixpunktverarbeitung durchführen (über die „WriteCheckpoint()"-Methode). Die ILogRecoverClerk-Schnittstelle ist durch die Programmauflistung 308 definiert, die in 11 dargestellt ist.
  • Die ILogRecoverClerkPhaseNotification-Schnittstelle. Der CRM-Clerk 222 verwirklicht die ILogRecoverClerkPhaseNotification-Schnittstelle. Wenn die Wiederherstellungsmaschine 242 von den Transaktionen, an welchen sie teilnimmt, Zweiphasen-Abschlussnotifikationen empfängt, benutzt die Wiederherstellungsmaschine die ILogRecoverClerkPhaseNotification-Schnittstelle, um die Notifikation an den CRM-Clerk 222 weiterzuleiten, der die Transaktion aufweist. Die ILogRecoverClerkPhaseNotification-Schnittstelle ist in der Programmauflistung 310 definiert, die in 12 dargestellt ist.
  • Die ILogRecoverClerkRegistration-Schnittstelle. Die Wiederherstellungsmaschine 242 unterstützt die ILogRecoverClerkRegistration-Schnittstelle, welche vom CRM-Wiederherstellungs-Clerk 224 und vom CRM-Clerk 222 aufgerufen wird, um sich im persistenten Log 226 zu registrieren. Wie oben beschrieben, registriert der CRM-Wiederherstellungs-Clerk 224 seine Klassenkennung (CLSID) beim Wiederherstellungs-Clerk, während der CRM-Clerk 222 eine Clerk-Instanzkennung registriert, die den CRM-Clerk 222 unter anderen CRM-Clerks derselben Klasse eindeutig identifiziert. Die ILogRecoverClerkRegistration-Schnittstelle ist in der Programmauflistung 312 definiert, die in 13 dargestellt ist.
  • Die ILog-Schnittstelle. Das Log-Objekt 240 verwirklicht die ILog-Schnitstelle, welche für den CRM-Clerk 222, den CRM-Wiederherstellungs-Clerk 224 und die Wiederherstellungsmaschine 242 Dienste zum stabilen Schreiben von Log-Aufzeichnungen in die Log-Datei 244 bereitstellt. Die ILog-Schnittstelle ist in der Programmauflistung 314 definiert, die in 14 dargestellt ist.
  • Nachdem die Prinzipien meiner Erfindung mit Bezug auf eine dargestellte Ausführungsform beschrieben und veranschaulicht worden sind, wird man erkennen, daß die dargestellte Ausführungsform in der Anordnung und den Einzelheiten modifiziert werden kann, ohne die Prinzipien zu verlassen. Es versteht sich, daß die hierin beschriebenen Programme, Verfahren oder Methoden nicht auf eine bestimmte Art von Computervorrichtung bezogen oder beschränkt sind, solange nicht anders angezeigt. Es können verschiedene Arten von allgemeinen oder spezialisierten Computervorrichtungen mit den hierin beschriebenen Lehren benutzt werden oder Operatio nen gemäß den hierin beschriebenen Lehren durchführen. Elemente der veranschaulichten Ausführungsform, die in Software dargestellt wurden, können auch in Hardware realisiert werden, und umgekehrt.
  • Während zum Beispiel die dargestellte CRM-Architektur 200 eine Schnittstelle (die „ICrmLog-Control::RegisterCompensator()"-Methode) bereitstellt, um den CRM-Kompensator 206 zu registrieren, können erfindungsgemäße kompensierende Ressourcenmanager alternativ eine Kennung (z. B. CLSID oder PROGID) des Kompensatorobjekts in die Log-Informationen loggen, die in das persistente Log 226 geschrieben werden, die von der vom System bereitgestellten Infrastruktur (z. B. dem CRM-Clerk 222 und dem CRM-Wiederherstellungs-Clerk 224) verwendet werden kann, um die Kompensatorkomponente zu erzeugen, um Zweiphasen-Abschlussnotifikationen des Transaktionsmanagers 148 (2) zu verarbeiten.
  • Im Hinblick auf die vielen möglichen Ausführungsformen, in welchen die Prinzipien meiner Erfindung angewendet werden können, sollte man erkennen, daß die detaillierten Ausführungsformen lediglich beispielhaft sind und nicht den Umfang meiner Erfindung beschränken sollen.

Claims (16)

  1. Computerlesbares Speicherungsmedium mit einem darauf gespeicherten computerausführbaren Programmcode eines komponentenbasierten Ressourcenmanagementgerüsts (200) zum Integrieren einer dauerhaften Ressource in ein Transaktionsbearbeitungssystem zum Teilnehmen an einer Transaktion unter der Steuerung durch einen Transaktionsmanager (148), wobei das Integrieren durch Verwendung einer Arbeiterkomponente (202) erfolgt, die dahingehend arbeitet, auf Anforderung durch eine Applikation (86) eine Arbeitsoperation an der dauerhaften Ressource auszuführen, wobei das komponentenbasierte Ressourcenmanagementgerüst (200) Folgendes umfasst: eine Logging-Komponente (222) mit einer Logging-Schnittstelle (230) für das Aufrufen durch die Arbeiterkomponente zum persistenten Loggen von Informationen der Arbeitsoperation und gekennzeichnet durch: eine Kompensatorkomponente (206), die dahingehend arbeitet, eine kompensierende Operation durchzuführen, die die Arbeitsoperation umkehrt; eine Kompensatorregistrierungskomponente (222) mit einer Kompensatorregistrationsschnittstelle zum Aufrufen durch die Arbeiterkomponente (202) zum Registrieren der Kompensatorkomponente (206); und eine Kompensationsinitiierungskomponente (222) mit einer Notifikationsschnittstelle zum Empfangen einer Notifikation von dem Transaktionsmanager (148), dass die Transaktion abgebrochen werden soll, und die dahingehend arbeitet, die registrierte Kompensatorkomponente (206) zu erzeugen, und weiterhin als Reaktion auf die Notifikation dahingehend arbeitet, zu bewirken, dass die Kompensatorkomponente (206) die kompensierende Operation auf der Basis der von der Arbeitskomponente (202) geloggten Informationen durchführt, um dadurch die Arbeitsoperation umzukehren.
  2. Computerlesbares Speicherungsmedium nach Anspruch 1, wobei die Kompensatorregistrierungskomponente (222) einen Zeiger auf die Logging-Schnittstelle (230) an die Arbeiterkomponente weitergibt bei Rückkehr von dem Arbeiterkomponentenaufruf an die Kompensatorregistrationsschnittstelle.
  3. Computerlesbares Speicherungsmedium nach Anspruch 1 oder 2, wobei die Kompensatorregistrierungskomponente (222) als Reaktion auf den Arbeiterkomponentenaufruf an die Kompensatorregistrationsschnittstelle dahingehend arbeitet, die Kompensationsinitiierungskomponente bei einer Transaktion zu beteiligen, an der die Arbeiterkomponente (202) teilnimmt, so dass die Kompensationsinitiierungskomponente (222) die Notifikation von dem Transaktionsmanager (148) empfängt.
  4. Computerlesbares Speicherungsmedium nach einem der vorhergehenden Ansprüche, wobei die Kompensationsinitiierungskomponente (222) dahingehend arbeitet, eine Vorbereitungsnotifikation von dem Transaktionsmanager (148) an der Notifikationsschnittstelle zu empfangen, und als Reaktion auf die Vorbereitungsnotifikation dahingehend arbeitet, zu bewirken, dass die Kompensatorkomponente (206) eine Abstimm-Operation durchführt, ob die Transaktion in einer Vorbereitungsphase der Transaktion abgebrochen werden soll.
  5. Computerlesbares Speicherungsmedium nach einem der vorhergehenden Ansprüche, wobei die Kompensationsinitiierungskomponente (222) dahingehend arbeitet, eine Abschlussnotifikation von dem Transaktionsmanager (148) an der Notifikationsschnittstelle zu empfangen, und als Reaktion auf die Abschlussnotifikation dahingehend arbeitet, zu bewirken, dass die Kompensatorkomponente (206) eine Bereinigungsoperation durchführt und jegliche reale Operation gemäß den geloggten Informationen zum Vervollständigen einer durch die Arbeitsoperation teilweise bewerkstelligten Arbeit.
  6. Kompensierender Ressourcenmanager (200) zum Verwalten einer dauerhaften Ressource zur Teilnahme an einer Transaktion unter der Steuerung eines Transaktionsmanagers (148) eines Online-Transaktionsbearbeitungssystems, wobei der kompensierende Ressourcenmanager (200) Folgendes umfasst: eine Arbeiterkomponente (202) mit einer Arbeitsanforderungsschnittstelle für das Aufrufen durch eine Applikation (86) zum Anfordern einer Arbeitsoperation an der dauerhaften Ressource als Teil der Transaktion, wobei die Arbeiterkomponente (202) als Reaktion auf den Applikationsaufruf dahingehend arbeitet, Informationen hinsichtlich der angeforderten Arbeitsoperation in ein Log (226) persistent zu schreiben und eine Arbeitsaktion zum Bewirken der Arbeitsoperation an der dauerhaften Ressource durchzuführen; und eine Kompensatorkomponente (206) mit einer Notifikationsschnittstelle (212) zum Empfangen einer von dem Transaktionsmanager (148) ausgegebenen Notifikation zum Abbrechen der Transaktion, wobei die Kompensatorkomponente (206) als Reaktion auf die Notifikation arbeitet, die Informationen aus dem Log (226) zu lesen und eine kompensierende Aktion zum Umkehren des Effekts der Arbeitsaktion an der dauerhaften Ressource durchzuführen; wobei die Arbeiterkomponente (202) und die Kompensatorkomponente (206) sich lediglich durch die von der Arbeiterkomponente geloggten Informationen einen Zustand teilen, gekennzeichnet durch einen Kompensationsmanager (222) mit einer Kompensatorregistrationsschnittstelle für das Aufrufen durch die Arbeiterkomponente (202) zum Registrieren der Kompensatorkomponente (206), wobei der Kompensationsmanager (222) als Reaktion auf den Arbeiterkomponentenaufruf arbeitet, die Kompensatorkomponente (206) zu erzeugen und sich an der Transaktion zum Empfangen der von dem Transaktionsmanager (148) ausgegebenen Notifikation zu beteiligen.
  7. Kompensierender Ressourcenmanager nach Anspruch 6, wobei der Kompensationsmanager (222) als Reaktion auf den Arbeiterkomponentenaufruf weiterhin dahingehend arbeitet, Zugang für die Arbeiterkomponente (202) zum Schreiben von Informationen in das Log (226) bereitzustellen.
  8. Kompensierender Ressourcenmanager nach Anspruch 6 oder 7 zur weiteren Wiederherstellung nach einem Ausfall während der Transaktion, wobei der kompensierende Ressourcenmanager Folgendes umfaßt: einen Wiederherstellungsmanager (224), der arbeitet, wenn eine Wiederherstellung nach der Nichtbestimmung eines Ergebnisses der Transaktion von dem Transaktionsmanager (148) initiiert wird, die Kompensatorkomponente (206) zu erzeugen und zu bewirken, dass die Kompensatorkomponente (206) die kompensierende Aktion auf der Basis der Informationen von dem Log (226) durchzuführen, wenn das Ergebnis war, die Transaktion abzubrechen.
  9. Kompensierender Ressourcenmanager nach Anspruch 8, wobei der Wiederherstellungsmanager (224) weiterhin arbeitet, wenn die Kompensatorkomponente (206) die kompensierende Aktion während der Wiederherstellung nicht durchführt, die Informationen im Log (226) beizubehalten, um die kompensierende Aktion auf eine spätere Wiederherstellung zu verschieben.
  10. Kompensierender Ressourcenmanager nach einem der Ansprüche 6 bis 9, wobei die Kompensatorkomponente (206), wenn die kompensierende Aktion während der Wiederherstellung nicht durchgeführt wird, dahingehend arbeitet zu bewirken, dass einem menschlichen Operator ein Hinweis und Informationen geliefert werden, damit der menschliche Operator eine manuelle Aktion ergreift, die eine Aktion an der Ressource umkehrt.
  11. Kompensierender Ressourcenmanager nach einem der Ansprüche 6 bis 10, wobei die kompensierende Aktion der Kompensatorkomponente (206) idempotent ist.
  12. Kompensierender Ressourcenmanager nach einem der Ansprüche 6 bis 11, wobei die kompensierende Aktion der Kompensatorkomponente (206) nicht reversibel ist.
  13. Verfahren zum Integrieren einer ausgewählten Ressource mit einem über einen Gerüstentwickler implementierten komponentenbasierten Transaktionsbearbeitungsgerüst, wenn die Ressource das Transaktionsbearbeitungsprotokoll des Gerüsts nicht unterstützt, wobei das Verfahren Folgendes umfasst: Abändern der Ressource durch eine Arbeiterkomponente (202), die einen von einem Zweitparteientwickler implementierten Code enthält; und wobei das Loggen und die Wiederherstellung der Ressource von dem Gerüst derart unterstützt werden, dass die Ressourcenabänderungen an der Ressource bei Transaktionsabschluss dauerhaft bleiben und die Ressource bei Transaktionsabbruch in einen Zustand vor der Transaktion zurückversetzt wird, gekennzeichnet durch die folgenden Schritte: Registrieren der Kompensationskomponente durch die Arbeiterkomponente; Wiedereinsetzen der Ressource durch die Kompensatorkomponente (206), die einen von dem Zweitparteientwickler implementierten Code enthält; und Empfangen einer Notifikation von einem Transaktionsmanager (148) über eine Notifikationsschnittstelle, dass die Transaktion abgebrochen werden soll, und als Reaktion auf die Notifikation Erzeugen der Kompensatorkomponente (206) und Bewirken, dass die Kompensatorkomponente (206) eine kompensierende Operation auf der Basis von von der Arbeiterkomponente (202) geloggten Informationen durchführt, um dadurch die von der Arbeiterkomponente (202) durchgeführte Arbeitsaktion umzukehren.
  14. Verfahren nach Anspruch 13, wobei die Arbeiterkomponente (202) mit der Kompensatorkomponente (206) assoziiert ist.
  15. Verfahren nach Anspruch 13 oder 14, weiterhin umfassend: Annehmen, an einer exponierten Schnittstelle, von Arbeiterkomponentenanforderungen zum Abändern der Ressource und Weiterleiten von während der Transaktion an der Ressource vorgenommenen Kompensatorkomponente-(206)-Abänderungen als Reaktion auf eine Transaktionsabschluss- oder -abbruchnotifikation.
  16. Verfahren nach Anspruch 15, weiterhin umfassend: Annehmen an einer exponierten Schnittstelle von Arbeiterkomponentenanforderungen zum Erzeugen eines Log-Service und Loggen von an der Ressource als Reaktion auf von der Kompensatorkomponente (206) vorgebrachten Anforderungen vorgenommene Änderungen.
DE69839145T 1998-06-30 1998-08-28 Kompensierender Betriebsmittelverwalter Expired - Lifetime DE69839145T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US114230 1987-10-27
US09/114,230 US6526416B1 (en) 1998-06-30 1998-06-30 Compensating resource managers

Publications (2)

Publication Number Publication Date
DE69839145D1 DE69839145D1 (de) 2008-04-03
DE69839145T2 true DE69839145T2 (de) 2009-03-05

Family

ID=22354077

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69839145T Expired - Lifetime DE69839145T2 (de) 1998-06-30 1998-08-28 Kompensierender Betriebsmittelverwalter

Country Status (5)

Country Link
US (1) US6526416B1 (de)
EP (1) EP0969363B1 (de)
JP (1) JP4159175B2 (de)
CA (1) CA2246908A1 (de)
DE (1) DE69839145T2 (de)

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6601069B2 (en) * 2000-12-15 2003-07-29 Hewlett-Packard Development Company, L.P. Synchronization using commitment
US7877421B2 (en) * 2001-05-25 2011-01-25 International Business Machines Corporation Method and system for mapping enterprise data assets to a semantic information model
US20030101170A1 (en) * 2001-05-25 2003-05-29 Joseph Edelstein Data query and location through a central ontology model
US7146399B2 (en) * 2001-05-25 2006-12-05 2006 Trident Company Run-time architecture for enterprise integration with transformation generation
US8412746B2 (en) * 2001-05-25 2013-04-02 International Business Machines Corporation Method and system for federated querying of data sources
US20060064666A1 (en) * 2001-05-25 2006-03-23 Amaru Ruth M Business rules for configurable metamodels and enterprise impact analysis
US7099885B2 (en) * 2001-05-25 2006-08-29 Unicorn Solutions Method and system for collaborative ontology modeling
US7383321B2 (en) * 2002-07-09 2008-06-03 Moyer Alan L Method and system for communicating between a remote printer and a server
US7437525B2 (en) 2001-05-31 2008-10-14 Oracle International Corporation Guaranteed undo retention
US7047386B1 (en) * 2001-05-31 2006-05-16 Oracle International Corporation Dynamic partitioning of a reusable resource
US20020194244A1 (en) * 2001-06-01 2002-12-19 Joan Raventos System and method for enabling transaction-based service utilizing non-transactional resources
US7171410B1 (en) * 2001-06-02 2007-01-30 Redback Networks, Inc. Fault tolerant network element
US20030126159A1 (en) * 2001-12-28 2003-07-03 Nwafor John I. Method and system for rollback of software system upgrade
US7916322B2 (en) * 2002-03-14 2011-03-29 Senshin Capital, Llc Method and apparatus for uploading content from a device to a remote network location
AU2003228512A1 (en) * 2002-04-10 2003-10-27 Instasolv, Inc. Method and system for managing computer systems
US7406486B1 (en) * 2002-04-10 2008-07-29 Oracle International Corporation Transforming transactions to increase parallelism when replicating
US8738568B2 (en) 2011-05-05 2014-05-27 Oracle International Corporation User-defined parallelization in transactional replication of in-memory database
US20040010540A1 (en) * 2002-07-09 2004-01-15 Puri Anish N. Method and system for streamlining data transfer between a content provider server and an output server
US7076508B2 (en) * 2002-08-12 2006-07-11 International Business Machines Corporation Method, system, and program for merging log entries from multiple recovery log files
WO2004025461A2 (en) * 2002-09-12 2004-03-25 International Business Machines Corporation A data processing system adapted to integrating non-homogeneous processes
US7103597B2 (en) * 2002-10-03 2006-09-05 Mcgoveran David O Adaptive transaction manager for complex transactions and business process
US7627817B2 (en) 2003-02-21 2009-12-01 Motionpoint Corporation Analyzing web site for translation
US7346905B2 (en) * 2003-06-10 2008-03-18 International Business Machines Corporation Apparatus and method for maintaining resource integrity without a unified transaction manager in a software environment
US7713116B2 (en) * 2003-06-30 2010-05-11 Microsoft Corporation Inventory management of virtual items in computer games
KR100659971B1 (ko) * 2003-12-26 2006-12-22 한국전자통신연구원 웹서비스 트랜잭션의 자동중단 처리시스템 및 방법
US7281153B2 (en) * 2004-04-14 2007-10-09 International Business Machines Corporation Apparatus, system, and method for transactional peer recovery in a data sharing clustering computer system
US7870426B2 (en) * 2004-04-14 2011-01-11 International Business Machines Corporation Apparatus, system, and method for transactional peer recovery in a data sharing clustering computer system
US20050243093A1 (en) * 2004-04-30 2005-11-03 Microsoft Corporation Universal controller help on a multimedia system
US7716669B2 (en) * 2004-04-30 2010-05-11 Microsoft Corporation Concurrent system applications in a multimedia console
US20050246638A1 (en) * 2004-04-30 2005-11-03 Microsoft Corporation Presenting in-game tips on a video game system
US8707317B2 (en) * 2004-04-30 2014-04-22 Microsoft Corporation Reserving a fixed amount of hardware resources of a multimedia console for system application and controlling the unreserved resources by the multimedia application
US7798903B2 (en) * 2004-04-30 2010-09-21 Microsoft Corporation System and method for accessing system software in a gaming console system via an input device
US8074220B2 (en) * 2004-05-21 2011-12-06 Computer Associates Think, Inc. System and method for interfacing an application to a distributed transaction coordinator
US8095826B1 (en) * 2004-06-29 2012-01-10 Symantec Operating Corporation Method and apparatus for providing in-memory checkpoint services within a distributed transaction
US7607125B2 (en) * 2004-11-11 2009-10-20 Microsoft Corporation Programming language support for integrating undo and exception handling
JP2006221352A (ja) * 2005-02-09 2006-08-24 Ntt Data Corp 異常系プロセス自動生成方法および異常系プロセス自動生成プログラム
EP1748384B1 (de) * 2005-04-06 2009-07-22 International Business Machines Corporation Verarbeitung von Kompensationsbereichen in Arbeitsflussverwaltungssystemen
US7949551B2 (en) 2005-04-06 2011-05-24 International Business Machines Corporation Processing of compensation scopes in workflow management systems
US20060288049A1 (en) * 2005-06-20 2006-12-21 Fabio Benedetti Method, System and computer Program for Concurrent File Update
US20070033592A1 (en) * 2005-08-04 2007-02-08 International Business Machines Corporation Method, apparatus, and computer program product for adaptive process dispatch in a computer system having a plurality of processors
US7856618B2 (en) * 2005-08-04 2010-12-21 International Business Machines Corporation Adaptively generating code for a computer program
US7890457B2 (en) * 2006-10-20 2011-02-15 Oracle International Corporation Transactionally consistent database workload replay
US7516128B2 (en) 2006-11-14 2009-04-07 International Business Machines Corporation Method for cleansing sequence-based data at query time
US7747899B2 (en) 2007-06-26 2010-06-29 Microsoft Corporation Providing mapping fault processing
US8566780B2 (en) 2007-06-26 2013-10-22 Microsoft Corporation Object model based mapping
US8166481B2 (en) * 2008-10-20 2012-04-24 Microsoft Corporation Transaction processing in transactional memory
US8499298B2 (en) 2010-01-28 2013-07-30 International Business Machines Corporation Multiprocessing transaction recovery manager
US9411793B2 (en) 2010-07-13 2016-08-09 Motionpoint Corporation Dynamic language translation of web site content
US20120331471A1 (en) * 2011-06-27 2012-12-27 Microsoft Corporation Executing molecular transactions
US9384302B2 (en) * 2013-06-17 2016-07-05 International Business Machines Corporation Generating differences for tuple attributes
US10430402B2 (en) 2015-01-16 2019-10-01 Red Hat, Inc. Distributed transaction with dynamic form
US10096065B2 (en) 2015-01-16 2018-10-09 Red Hat, Inc. Distributed transactions with extended locks
US10901776B2 (en) 2017-12-04 2021-01-26 Red Hat, Inc. Efficient and scalable transaction processing using a consensus-based transaction model

Family Cites Families (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4752928A (en) 1985-05-06 1988-06-21 Tektronix, Inc. Transaction analyzer
US5125091A (en) 1989-06-08 1992-06-23 Hazox Corporation Object oriented control of real-time processing
EP0414624B1 (de) 1989-08-24 1996-12-18 International Business Machines Corporation System für den Aufruf von Prozeduren von einem Fernnetzwerkknotenpunkt
US5151987A (en) 1990-10-23 1992-09-29 International Business Machines Corporation Recovery objects in an object oriented computing environment
US5212793A (en) 1991-09-04 1993-05-18 International Business Machines Corp. Generic initiators
US5278982A (en) * 1991-12-23 1994-01-11 International Business Machines Corporation Log archive filtering method for transaction-consistent forward recovery from catastrophic media failures
CA2099918C (en) 1992-07-06 2002-11-19 Robert G. Atkinson Method and system for naming and binding objects
JP3181592B2 (ja) 1992-12-01 2001-07-03 マイクロソフト コーポレイション 埋め込まれたオブジェクトとイン・プレース対話するための方法及びシステム
EP0613083B1 (de) 1993-02-25 2002-01-23 Sun Microsystems, Inc. Transaktionsverwaltung in objektorientiertem System
JP2557192B2 (ja) 1993-03-15 1996-11-27 インターナショナル・ビジネス・マシーンズ・コーポレイション トランザクション処理の同期方法、トランザクション処理のモニタ方法及びトランザクションのコミット処理方法
US5377350A (en) 1993-04-30 1994-12-27 International Business Machines Corporation System for cooperative communication between local object managers to provide verification for the performance of remote calls by object messages
US5577252A (en) 1993-07-28 1996-11-19 Sun Microsystems, Inc. Methods and apparatus for implementing secure name servers in an object-oriented system
US5455953A (en) 1993-11-03 1995-10-03 Wang Laboratories, Inc. Authorization system for obtaining in single step both identification and access rights of client to server directly from encrypted authorization ticket
US5517645A (en) 1993-11-05 1996-05-14 Microsoft Corporation Method and system for interfacing components via aggregate components formed by aggregating the components each with an instance of a component manager
JPH07262072A (ja) 1994-03-16 1995-10-13 Fuji Xerox Co Ltd ファイル管理装置
US5706429A (en) 1994-03-21 1998-01-06 International Business Machines Corporation Transaction processing system and method
US6330582B1 (en) 1994-03-21 2001-12-11 International Business Machines Corporation Apparatus and method enabling a client to control transaction message traffic between server and client processes
US5524238A (en) 1994-03-23 1996-06-04 Breakout I/O Corporation User specific intelligent interface which intercepts and either replaces or passes commands to a data identity and the field accessed
US5864683A (en) 1994-10-12 1999-01-26 Secure Computing Corporartion System for providing secure internetwork by connecting type enforcing secure computers to external network for limiting access to data based on user and process access rights
US5687370A (en) 1995-01-31 1997-11-11 Next Software, Inc. Transparent local and distributed memory management system
US5822585A (en) 1995-02-21 1998-10-13 Compuware Corporation System and method for cooperative processing using object-oriented framework
US5802291A (en) 1995-03-30 1998-09-01 Sun Microsystems, Inc. System and method to control and administer distributed object servers using first class distributed objects
US5797015A (en) 1995-04-18 1998-08-18 Pitney Bowes Inc. Method of customizing application software in inserter systems
US5889957A (en) 1995-06-07 1999-03-30 Tandem Computers Incorporated Method and apparatus for context sensitive pathsend
US5941947A (en) 1995-08-18 1999-08-24 Microsoft Corporation System and method for controlling access to data entities in a computer network
US5717439A (en) 1995-10-10 1998-02-10 Xerox Corporation Hierarchy of saving and retrieving control templates
US5764958A (en) 1995-11-30 1998-06-09 International Business Machines Corporation Method and apparatus for creating dynamic roles with a system object model
US5815665A (en) 1996-04-03 1998-09-29 Microsoft Corporation System and method for providing trusted brokering services over a distributed network
US5857204A (en) * 1996-07-02 1999-01-05 Ab Initio Software Corporation Restoring the state of a set of files
US6253252B1 (en) 1996-07-11 2001-06-26 Andrew Schofield Method and apparatus for asynchronously calling and implementing objects
US5781910A (en) 1996-09-13 1998-07-14 Stratus Computer, Inc. Preforming concurrent transactions in a replicated database environment
US5884327A (en) 1996-09-25 1999-03-16 International Business Machines Corporation System, method and program for performing two-phase commit with a coordinator that performs no logging
US5884316A (en) 1996-11-19 1999-03-16 Microsoft Corporation Implicit session context system with object state cache
US6094688A (en) 1997-01-08 2000-07-25 Crossworlds Software, Inc. Modular application collaboration including filtering at the source and proxy execution of compensating transactions to conserve server resources
US5913061A (en) 1997-01-08 1999-06-15 Crossroads Software, Inc. Modular application collaboration
US5933593A (en) 1997-01-22 1999-08-03 Oracle Corporation Method for writing modified data from a main memory of a computer back to a database
US5875291A (en) 1997-04-11 1999-02-23 Tandem Computers Incorporated Method and apparatus for checking transactions in a computer system
US5881225A (en) 1997-04-14 1999-03-09 Araxsys, Inc. Security monitor for controlling functional access to a computer system
US6105147A (en) 1997-04-16 2000-08-15 Compaq Computer Corporation Using process pairs as transaction-coordinated resource managers
US6026428A (en) 1997-08-13 2000-02-15 International Business Machines Corporation Object oriented thread context manager, method and computer program product for object oriented thread context management
US5890161A (en) 1997-10-28 1999-03-30 Microsoft Corporation Automatic transaction processing of component-based server applications
US5958004A (en) 1997-10-28 1999-09-28 Microsoft Corporation Disabling and enabling transaction committal in transactional application components

Also Published As

Publication number Publication date
US6526416B1 (en) 2003-02-25
EP0969363A3 (de) 2003-05-28
DE69839145D1 (de) 2008-04-03
EP0969363B1 (de) 2008-02-20
CA2246908A1 (en) 1999-12-30
JP4159175B2 (ja) 2008-10-01
JP2000020364A (ja) 2000-01-21
EP0969363A2 (de) 2000-01-05

Similar Documents

Publication Publication Date Title
DE69839145T2 (de) Kompensierender Betriebsmittelverwalter
EP0929864B1 (de) Koordinations-system
Miller et al. WebWork: METEOR 2's web-based workflow management system
US6138143A (en) Method and apparatus for asynchronous transaction processing
DE69733266T2 (de) Ausfallsicheres und ereignisgesteuertes transaktions-system und verfahren
EP0772136B1 (de) Bindungsverfahren in einer Transaktion in einer verteilten Datenbank
US5923833A (en) Restart and recovery of OMG-compliant transaction systems
US6597366B1 (en) Transparent general purpose object isolation for multi-tier distributed object environments
DE19926115B4 (de) Transaktionshandhabung in einer Konfigurationsdatenbank
DE4216871A1 (de) Ausfuehrungsordnen zum sicherstellen der serienherstellbarkeit verteilter transaktionen
DE4420451C2 (de) Sperrmechanismus für ein CHECK-IN/CHECK-OUT-Modell
DE19705955A1 (de) Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung
DE10003015A1 (de) Die Erzeugung von Ereignis-Bedingungs-Aktions-Regeln aus Prozessmodellen
Hagen et al. Beyond the black box: Event-based inter-process communication in process support systems
DE10128883A1 (de) Verfahren und System für die Verteilung von Anwendungsdaten auf verteilte Datenbanken mit verschiedenen Formaten
DE10392709T5 (de) Systeme und Verfahren zum Prädizieren von Arbeitslisten
DE112010004808T5 (de) Gleichzeitige Ausführung einer Anforderungsverarbeitung und von Analysen von Anforderungen
DE10038289A1 (de) Verfahren und System zur Integration von Basisbanktätigkeiten (Core Banking System)
WO2000045286A9 (en) Method and apparatus for distributed database access
Horswill Designing and Programming CICS Applications
Haghjoo et al. A semantic-based nested transaction model for intelligent and cooperative information systems
Laing et al. Transaction Management Support in the VMS Operating System Kernel
Little et al. An examination of the transition of the arjuna distributed transaction processing software from research to products
EP1691290B1 (de) Verfahren zur Sicherung einer Datenbank und Vorrichtung zur Durchführung des Verfahrens
Pu et al. Execution autonomy in distributed transaction processing

Legal Events

Date Code Title Description
8364 No opposition during term of opposition