Freigeben über

Grundlegendes zu TPS-Komponenten

Jedes Transaktionsverarbeitungssystem (TPS), das den Kernel Transaction Manager (KTM) und das Common Log File System (CLFS) verwendet, sollte die folgenden wichtigen Komponenten enthalten:

  • Transaktionsmanager (KTM)

    KTM verfolgt den Zustand der einzelnen Transaktionen und koordiniert den Wiederherstellungsvorgang nach einem Systemabsturz.

  • Mindestens ein Ressourcenmanager

    Ressourcenmanager, die Sie bereitstellen, verwalten die daten, die den einzelnen Transaktionen zugeordnet sind.

  • Mindestens ein CLFS-Logdatenstrom

    Der Transaktions-Manager und Ressourcenmanager verwenden CLFS-Protokolldatenströme, um Informationen aufzuzeichnen, die sie zum Commit, Rollback oder Wiederherstellen einer Transaktion verwenden können.

  • Mindestens ein Transaktionsclient

    In der Regel kann jeder Transaktionsclient Ihres TPS eine Transaktion erstellen, Vorgänge für Daten im Kontext der Transaktion ausführen und dann entweder einen Commit- oder Rollbackvorgang für die Transaktion initiieren.

In diesem Artikel werden Sie mit einem einfachen TPS mit einem Ressourcen-Manager, einem komplexeren TPS, der mehrere Ressourcenmanager und einige andere TPS-Szenarien enthält, vorgestellt.

Der Abschnitt "Using KTM " enthält ausführliche Informationen zur Verwendung von KTM zum Erstellen von TPS-Komponenten.

Einfache TPS

Ein einfacher TPS kann aus KTM, einem Ressourcenmanager und CLFS bestehen. Transaktionsclients können mit dem Ressourcen-Manager über eine Schnittstelle kommunizieren, die der Ressourcen-Manager bereitstellt.

Angenommen, Sie möchten ein Datenbankverwaltungssystem erstellen. Sie möchten, dass die Clients des Systems auf die Datenbank zugreifen, indem Sie ein Handle für ein Datenbankobjekt öffnen, Lese- und Schreibvorgänge für das Objekt ausführen und dann das Objekthandle schließen.

Angenommen, Sie möchten, dass Sätze von Lese- und Schreibvorgängen atomisch ausgeführt werden sollen, damit andere Benutzer des Systems nur das Endergebnis sehen. Sie können dieses Ziel erreichen, indem Sie ein TPS entwerfen, mit dem Clients Sätze von Datenbankvorgängen an eine Transaktion binden können.

Ihr System sollte einen Ressourcenmanager enthalten, der die Daten in der Datenbank als Reaktion auf Lese- und Schreibanforderungen von Clients verwaltet. Dieser Ressourcen-Manager könnte eine Api (Application Programming Interface) exportieren, mit der Clients eine Transaktion einem Satz von Lese- und Schreibvorgängen zuordnen können.

Wenn Sie Ihren Ressourcen-Manager laden, muss er sich bei KTM registrieren, indem ZwCreateTransactionManager und ZwCreateResourceManager aufgerufen werden. Anschließend kann der Ressourcenmanager an Transaktionen teilnehmen.

Möglicherweise möchten Sie, dass der Ressourcenmanager eine Reihe von Funktionen unterstützt, mit denen Clients Datenobjekte erstellen, Daten lesen und schreiben können, die den Datenobjekten zugeordnet sind, und die Datenobjekte schließen. Der folgende Pseudocode zeigt eine Beispielcodesequenz von einem Client.

CreateDataObject (IN TransactionID, OUT DataHandle);
ReadData (IN DataHandle, OUT Data);
WriteData (IN DataHandle, IN Data);
WriteData (IN DataHandle, IN Data);
WriteData (IN DataHandle, IN Data);
CloseDataObject (IN DataHandle);

Bevor ein Client die CreateDataObject-Routine Ihres Ressourcenmanagers aufrufen kann, muss der Client ein Transaktionsobjekt erstellen, indem er die ZwCreateTransaction-Routine von KTM aufruft und den Bezeichner des Transaktionsobjekts durch Aufrufen von ZwQueryInformationTransaction abruft.

Wenn der Client die CreateDataObject-Routine des Ressourcenmanagers aufruft, übergibt der Client den Bezeichner des Transaktionsobjekts an den Ressourcen-Manager. Der Ressourcenmanager kann ZwOpenTransaction aufrufen, um ein Handle für das Transaktionsobjekt abzurufen, und dann kann er ZwCreateEnlistment aufrufen, um seine Teilnahme an der Transaktion zu registrieren.

An diesem Punkt kann der Client mit der Durchführung von Vorgängen für das Datenobjekt beginnen. Da der Client beim Erstellen des Datenobjekts einen Transaktionsbezeichner bereitgestellt hat, kann der Ressourcenmanager alle Lese- und Schreibvorgänge der Transaktion zuweisen.

Der Ressourcenmanager muss alle Ergebnisse von Datenvorgängen aufzeichnen, die der Client angibt, ohne die Ergebnisse dauerhaft zu machen. In der Regel verwendet der Ressourcen-Manager CLFS zum Aufzeichnen des Vorgangsergebnisse in einem Transaktionsprotokolldatenstrom.

Wenn der Client mit dem Aufruf des Ressourcen-Managers für die Durchführung von Transaktionsvorgängen fertig ist, ruft er die ZwCommitTransaction-Routine von KTM auf. Zu diesem Zeitpunkt benachrichtigt KTM den Ressourcenmanager darüber, dass er den Betrieb dauerhaft machen sollte. Der Ressourcenmanager verschiebt dann die Vorgangsergebnisse aus dem Protokolldatenstrom in das permanente Speichermedium der Daten. Schließlich ruft der Ressourcenmanager ZwCommitComplete auf, um KTM darüber zu informieren, dass der Commit-Vorgang abgeschlossen ist.

Was geschieht, wenn Der Ressourcenmanager einen Fehler für einen der Aufrufe des Clients an ReadData oder WriteData meldet? Der Client kann ZwRollbackTransaction aufrufen, um die Transaktion zurückzurufen. Aufgrund dieses Aufrufs benachrichtigt KTM den Ressourcenmanager darüber, dass sie die Daten in ihrem ursprünglichen Zustand wiederherstellen sollte. Anschließend kann der Client entweder eine neue Transaktion für dieselben Vorgänge erstellen, oder er kann sich entscheiden, den Vorgang nicht fortzusetzen.

Der folgende Pseudocode zeigt ein Beispiel für eine detailliertere Sequenz der Transaktionsvorgänge eines Clients.

    ZwCreateTransaction (&TransactionHandle, ...);
    ZwQueryInformationTransaction (TransactionHandle, ...);
    CreateDataObject (TransactionID, &DataHandle);
    Status = ReadData (DataHandle, &Data1);
    if (Status == Error) goto ErrorRollback;
    Status = WriteData (DataHandle, Data2);
    if (Status == Error) goto ErrorRollback;
    Status = WriteData (DataHandle, Data3);
    if (Status == Error) goto ErrorRollback;
    Status = WriteData (DataHandle, Data4);
    if (Status == Error) goto ErrorRollback;
    ZwCommitTransaction (TransactionHandle, ...);
    goto Leave;
ErrorRollback:
    ZwRollbackTransaction (TransactionHandle, ...);
Leave:
    ZwClose (TransactionHandle);
    return;

Was geschieht, wenn das System nach der Erstellung der Transaktion einen Absturz erleidet, aber bevor diese zugesichert oder zurückgesetzt wird? Jedes Mal, wenn der Ressourcen-Manager geladen wird, sollte er ZwRecoverTransactionManager und ZwRecoverResourceManager aufrufen. Das Aufrufen von ZwRecoverTransactionManager bewirkt, dass KTM seinen Protokolldatenstrom öffnet und den Transaktionsverlauf liest. Das Aufrufen von ZwRecoverResourceManager bewirkt, dass KTM den Ressourcenmanager über alle in Bearbeitung enlisteten Transaktionen benachrichtigt, die vor dem Absturz ausgeführt wurden und welche Transaktionen der Ressourcenmanager daher wiederherstellen muss.

Wenn ein Transaktionsclient ZwCommitTransaction für eine Transaktion vor dem Absturz aufrief und begonnen hat, Commitvorgänge für die Transaktion zu verarbeiten, muss der Ressourcenmanager in der Lage sein, den Status der Transaktion unmittelbar vor dem Absturz wiederherzustellen. Wenn der Client nicht bereit war, die Transaktion vor dem Absturz zu übernehmen, kann der Ressourcenmanager die Daten verwerfen und die Transaktion zurücksetzen.

Weitere Informationen zum Schreiben von Transaktionsclients finden Sie unter Creating a Transactional Client.

Weitere Informationen zum Schreiben von Ressourcenmanagern finden Sie unter Erstellen eines Ressourcen-Managers.

Mehrere Ressourcenmanager in einem TPS

Angenommen, Ihr TPS ermöglicht Es Clients, Informationen in zwei separaten Datenbanken innerhalb einer einzelnen Transaktion zu ändern, sodass die Transaktion nur erfolgreich ist, wenn die Änderungen beider Datenbanken erfolgreich sind.

In diesem Fall kann Ihr TPS über zwei Ressourcenmanager verfügen, eine für jede Datenbank. Jeder Ressourcen-Manager kann eine API exportieren, die Clients für den Zugriff auf die Datenbank des Ressourcen-Managers verwenden können.

Der folgende Pseudocode zeigt, wie ein Client eine einzelne Transaktion erstellen kann, die Vorgänge in zwei Datenbanken enthält, die von zwei Ressourcenmanagern unterstützt werden.

In diesem Beispiel liest der Client Daten aus der ersten Datenbank und schreibt sie in die zweite Datenbank. Anschließend liest der Client Daten aus der zweiten Datenbank und schreibt sie in die erste Datenbank. (Der erste Ressourcen-Manager exportiert Funktionen, die mit Rm1 beginnen, und der zweite Ressourcen-Manager exportiert Funktionen, die mit Rm2 beginnen.)

    ZwCreateTransaction (&TransactionHandle, ...);
    ZwQueryInformationTransaction (TransactionHandle, ...);
    Rm1CreateDataObject (TransactionID, &Rm1DataHandle);
    Rm2CreateDataObject (TransactionID, &Rm2DataHandle);
    Status = Rm1ReadData (Rm1DataHandle, &Rm1Data);
    if (Status == Error) goto ErrorRollback;
    Status = Rm2WriteData (Rm2DataHandle, Rm1Data);
    if (Status == Error) goto ErrorRollback;
    Status = Rm2ReadData (Rm2DataHandle, &Rm2Data);
    if (Status == Error) goto ErrorRollback;
    Status = Rm1WriteData (Rm1DataHandle, Rm2Data);
    if (Status == Error) goto ErrorRollback;
    ZwCommitTransaction (TransactionHandle, ...);
    goto Leave;
ErrorRollback:
    ZwRollbackTransaction (TransactionHandle, ...);
Leave:
    ZwClose (TransactionHandle);
    return;

Da der Client denselben Transaktionsbezeichner an beide Ressourcenmanager übergibt, können beide Ressourcenmanager ZwOpenTransaction und ZwCreateEnlistment aufrufen, um die Transaktion aufzurufen. Wenn der Client schließlich ZwCommitTransactionaufruft, benachrichtigt KTM jeden Ressourcenmanager, dass der Manager die Vorgänge dauerhaft durchführen soll, und jeder Ressourcenmanager ruft ZwCommitComplete nach Abschluss des Vorgangs auf.

Andere TPS-Szenarien

KTM unterstützt andere TPS-Szenarien. In den folgenden Szenarien werden beispielsweise Komponenten beschrieben, die ein TPS enthalten kann:

  • Ein Ressourcenmanager, der mehrere Datenbanken verwaltet.

    Die API des Ressourcenmanagers könnte Clients das Gleichzeitige Öffnen und Zugreifen auf mehrere Datenbanken ermöglichen, und der Client könnte Zugriffe auf mehrere Datenbanken in einer einzigen Transaktion kombinieren.

  • Ein Ressourcen-Manager mit einer API, die Clients aufrufen, und andere Ressourcenmanager mit APIs, die der erste Ressourcen-Manager aufruft.

    Der Client kommuniziert nur mit dem ersten Ressourcen-Manager. Wenn dieser Ressourcenmanager Anforderungen von einem Client verarbeitet, kann er bei Bedarf auf die zusätzlichen Ressourcenmanager zugreifen, um die Anforderungen des Clients zu verarbeiten. Beispielsweise verwaltet ein Ressourcenmanager eine datenbank mit Clientzugriff, auf die Sicherungs- oder Datenüberprüfungsvorgänge von einem zweiten Ressourcen-Manager erforderlich sind, auf den Clients nicht zugreifen können.

  • Ein vorhandener Client- und Ressourcenmanager, der NICHT KTM verwendet, ist in einen zusätzlichen Satz von Ressourcenmanagern integriert, die KTM verwenden.

    In diesem Fall müssen Sie den vorhandenen Ressourcenmanager in der Regel so ändern, dass er zu einem überlegenen Transaktionsmanager wird, der mit KTM kommuniziert.

  • Last updated on