Sdílet prostřednictvím

Pochopení komponent TPS

Jakýkoli systém zpracování transakcí (TPS), který používá Správce transakcí jádra (KTM) a common Log File System (CLFS) by měl obsahovat následující důležité komponenty:

  • Správce transakcí (KTM)

    KTM sleduje stav každé transakce a koordinuje operace obnovení po chybovém ukončení systému.

  • Jeden nebo více správců zdrojů

    Správci prostředků, které poskytujete, spravují data přidružená k jednotlivým transakcím.

  • Jeden nebo více CLFS streamů protokolů

    Správce transakcí a správci prostředků používají streamy protokolů CLFS k zaznamenávání informací, které mohou použít k potvrzení, vrácení zpět nebo obnovení transakce.

  • Jeden nebo více transakčních klientů

    Každý transakční klient vašeho TPS obvykle může vytvořit transakci, provádět operace s daty v kontextu transakce a pak zahájit buď operaci potvrzení nebo vrácení zpět transakce.

Tento článek vás seznámí s jednoduchým čipem TPS s jedním správcem prostředků, složitějším čipem TPS, který obsahuje více správců prostředků, a některé další scénáře TPS.

V části Použití KTM najdete podrobné informace o tom, jak pomocí KTM vytvářet komponenty TPS.

Jednoduché TPS

Jednoduchý TPS se může skládat z KTM, jednoho správce prostředků a CLFS. Transakční klienti můžou komunikovat se správcem prostředků prostřednictvím rozhraní, které správce prostředků poskytuje.

Předpokládejme například, že chcete vytvořit systém pro správu databází. Chcete, aby klienti systému měli přístup k databázi otevřením popisovače databázovému objektu, prováděním operací čtení a zápisu objektu a zavřením popisovače objektu.

Teď předpokládejme, že chcete, aby sady operací čtení a zápisu probíhaly atomicky, aby ostatní uživatelé systému viděli pouze konečný výsledek. Tohoto cíle můžete dosáhnout návrhem čipu TPS, který klientům umožňuje svázat sady databázových operací s transakcí.

Váš systém by měl obsahovat správce prostředků, který spravuje data v databázi v reakci na žádosti o čtení a zápis od klientů. Tento správce prostředků by mohl exportovat aplikační programovací rozhraní (API), které klientům umožňuje přidružit transakci k sadě operací čtení a zápisu.

Když načtete správce prostředků, musí se zaregistrovat v KTM voláním ZwCreateTransactionManager a ZwCreateResourceManager. Správce prostředků se pak může účastnit transakcí.

Můžete chtít, aby správce prostředků podporoval sadu funkcí, které klientům umožňují vytvářet datové objekty, číst a zapisovat data přidružená k datovým objektům a zavřít datové objekty. Následující pseudokód ukazuje ukázkovou posloupnost kódu z klienta.

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);

Než klient může volat rutinu CreateDataObject správce prostředků, musí vytvořit objekt transakce zavoláním rutiny ZwCreateTransaction a získat identifikátor objektu transakce voláním ZwQueryInformationTransaction.

Když klient volá rutinu CreateDataObject správce prostředků, klient předá identifikátor objektu transakce správci prostředků. Správce prostředků může volat ZwOpenTransaction a získat popisovač objektu transakce, a pak může volat ZwCreateEnlistment k registraci své účasti v transakci.

V tomto okamžiku může klient zahájit operace s datovým objektem. Vzhledem k tomu, že klient zadal identifikátor transakce při vytváření datového objektu, správce prostředků může přiřadit transakce všechny operace čtení a zápisu.

Správce prostředků musí zaznamenávat všechny výsledky datových operací, které klient určí, aniž by byly výsledky trvalé. Správce prostředků obvykle používá CLFS k zaznamenání výsledků operace ve streamu transakčního protokolu.

Když klient dokončí volání správce prostředků k provádění transakčních operací, volá rutinu KTM ZwCommitTransaction. V tomto okamžiku nástroj KTM upozorní správce prostředků, že by měl provádět operace jako trvalé. Správce prostředků pak přesune výsledky operace ze streamu protokolu do trvalého úložného média dat. Správce prostředků nakonec zavolá ZwCommitComplete, aby informoval KTM o dokončení operace potvrzení.

Co se stane, když správce prostředků hlásí chybu u jednoho z volání klienta pro ReadData nebo WriteData? Klient může volat ZwRollbackTransaction k vrácení transakce zpět. V důsledku tohoto volání KTM upozorní správce prostředků, že má obnovit data do původního stavu. Klient pak může buď vytvořit novou transakci pro stejné operace, nebo se může rozhodnout, že nebude pokračovat.

Následující pseudokód ukazuje příklad podrobnější sekvence transakčních operací klienta.

    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;

Co se stane, když po vytvoření transakce systém havaruje, ale před potvrzením nebo vrácením zpět? Pokaždé, když se správce prostředků načte, by měl volat ZwRecoverTransactionManager a ZwRecoverResourceManager. Volání ZwRecoverTransactionManager způsobí, že KTM otevře stream protokolu a přečte historii transakcí. Volání ZwRecoverResourceManager způsobí, že KTM oznámí správci prostředků všechny transakce, které byly zapojeny před selháním, a které musí správce prostředků následně obnovit.

Pokud transakční klient zavolal funkci ZwCommitTransaction pro transakci před selháním a začal zpracovávat operace potvrzení pro transakci, správce prostředků musí být schopen obnovit stav transakce do bodu bezprostředně před selháním. Pokud klient nebyl připravený k potvrzení transakce před chybovým ukončením, správce prostředků může zahodit data a vrátit transakce zpět.

Další informace o zápisu transakčních klientů naleznete v tématu Vytvoření transakčního klienta.

Další informace o tom, jak psát správce prostředků, naleznete v tématu Vytvoření Resource Manageru.

Více správců prostředků v TPS

Předpokládejme, že váš čip TPS umožňuje klientům upravovat informace ve dvou samostatných databázích v rámci jedné transakce, aby transakce byla úspěšná pouze v případě, že změny obou databází proběhly úspěšně.

V takovém případě může mít váš transakční systém (TPS) dva správce prostředků, jednoho pro každou databázi. Každý správce prostředků může exportovat rozhraní API, které můžou klienti použít pro přístup k databázi Resource Manageru.

Následující pseudokód ukazuje, jak může klient vytvořit jednu transakci, která obsahuje operace ve dvou databázích, které dva správci prostředků podporují.

V tomto příkladu klient načte data z první databáze a zapíše je do druhé databáze. Klient pak načte data z druhé databáze a zapíše je do první databáze. (První správce prostředků exportuje funkce, které začínají Rm1, a druhý správce prostředků exportuje funkce, které začínají Rm2.)

    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;

Protože klient předává stejný identifikátor transakce dvěma správcům prostředků, oba správci prostředků mohou volat ZwOpenTransaction a ZwCreateEnlistment pro zařazení do transakce. Když klient nakonec zavolá ZwCommitTransaction, KTM upozorní každého správce prostředků, že správce by měl provádět operace trvalé a každý správce prostředků volá ZwCommitComplete po dokončení.

Další scénáře TPS

KTM podporuje další scénáře TPS. Například následující scénáře popisují komponenty, které může čip TPS obsahovat:

  • Jeden správce prostředků, který spravuje více databází.

    Rozhraní API Resource Manageru může klientům umožnit otevírat a přistupovat k více databázím najednou a klient může kombinovat přístup k více databázím v jedné transakci.

  • Jeden správce prostředků s rozhraním API, které klienti volají, a další správci prostředků s rozhraními API, která volá první správce prostředků.

    Klient komunikuje pouze s prvním správcem prostředků. Když správce prostředků zpracovává požadavky od klienta, může podle potřeby přistupovat k dalším správcům prostředků, aby mohl zpracovávat požadavky klienta. Správce prostředků například spravuje databázi přístupnou klientem, která vyžaduje operace zálohování nebo ověření dat z druhého správce prostředků, ke kterému nemají klienti přístup.

  • Existující klienti a správci prostředků, kteří nepoužívají KTM, jsou integrováni s další sadou správců prostředků, kteří používají KTM.

    V tomto případě obvykle musíte upravit existujícího správce prostředků tak, aby se stal nadřízeným správcem transakcí komunikujícím s KTM.

  • Last updated on