Udostępnij przez

Opis składników TPS

Każdy system przetwarzania transakcji (TPS), który używa Menedżera transakcji jądra (KTM) i Common Log File System (CLFS) powinien zawierać następujące ważne składniki:

  • Menedżer transakcji (KTM)

    KTM śledzi stan każdej transakcji i koordynuje operacje odzyskiwania po awarii systemu.

  • Co najmniej jeden menedżer zasobów

    Menedżerowie zasobów, których udostępniasz, zarządzają danymi skojarzonymi z każdą transakcją.

  • Co najmniej jeden strumień dziennika CLFS

    Menedżer transakcji i menedżerowie zasobów używają strumieni dzienników CLFS do rejestrowania informacji, których mogą używać do zatwierdzania, wycofywania lub odzyskiwania transakcji.

  • Co najmniej jeden klientów transakcyjnych

    Zazwyczaj każdy transakcyjny klient TPS może utworzyć transakcję, wykonać operacje na danych w jej kontekście, a następnie zainicjować operację zatwierdzenia lub wycofania transakcji.

Ten artykuł zawiera wprowadzenie do prostego modułu TPS z jednym menedżerem zasobów, bardziej złożonym modułem TPS zawierającym wiele menedżerów zasobów i innymi scenariuszami TPS.

Sekcja Using KTM dostarcza szczegółowych informacji o tym, jak używać KTM do tworzenia komponentów TPS.

Prosty moduł TPS

Prosty moduł TPS może składać się z KTM, jednego menedżera zasobów i środowiska CLFS. Klienci transakcyjni mogą komunikować się z menedżerem zasobów za pośrednictwem interfejsu udostępnianego przez menedżera zasobów.

Załóżmy na przykład, że chcesz utworzyć system zarządzania bazami danych. Klienci systemu mają uzyskiwać dostęp do bazy danych, otwierając dojście do obiektu bazy danych, wykonując operacje odczytu i zapisu na obiekcie, a następnie zamykając uchwyt obiektu.

Teraz załóżmy, że chcesz, aby zestawy operacji odczytu i zapisu były wykonywane niepodzielnie, tak aby inni użytkownicy systemu widzieli tylko końcowy wynik. Ten cel można osiągnąć, projektując moduł TPS, który umożliwia klientom wiązanie zestawów operacji bazy danych z transakcją.

System powinien zawierać menedżera zasobów, który zarządza danymi w bazie danych w odpowiedzi na żądania odczytu i zapisu od klientów. Ten menedżer zasobów może wyeksportować interfejs programowania aplikacji (API), który umożliwia klientom skojarzenie transakcji z zestawem operacji odczytu i zapisu.

Gdy ładujesz menedżera zasobów, musi on sam zarejestrować się w usłudze KTM, wywołując funkcje ZwCreateTransactionManager i ZwCreateResourceManager. Następnie menedżer zasobów może uczestniczyć w transakcjach.

Menedżer zasobów może chcieć obsługiwać zestaw funkcji, które umożliwiają klientom tworzenie obiektów danych, odczytywanie i zapisywanie danych skojarzonych z obiektami danych i zamykanie obiektów danych. Poniższy pseudokod przedstawia przykładową sekwencję kodu 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);

Aby klient mógł wywołać procedurę CreateDataObject menedżera zasobów, musi utworzyć obiekt transakcji, wywołując procedurę ZwCreateTransaction KTM i uzyskać identyfikator obiektu transakcji, wywołując ZwQueryInformationTransaction.

Gdy klient wywołuje procedurę CreateDataObject menedżera zasobów, klient przekazuje identyfikator obiektu transakcji do menedżera zasobów. Menedżer zasobów może wywołać ZwOpenTransaction w celu uzyskania dojścia do obiektu transakcji, a następnie wywołać ZwCreateEnlistment, aby zarejestrować udział w transakcji.

W tym momencie klient może rozpocząć wykonywanie operacji na obiekcie danych. Ponieważ klient podał identyfikator transakcji podczas tworzenia obiektu danych, menedżer zasobów może przypisać wszystkie operacje odczytu i zapisu do transakcji.

Menedżer zasobów musi rejestrować wszystkie wyniki operacji danych, które klient określa, bez trwałego zapisywania wyników. Zazwyczaj menedżer zasobów używa środowiska CLFS do rejestrowania wyników operacji w strumieniu dziennika transakcji.

Gdy klient zakończy wywoływanie menedżera zasobów w celu przeprowadzenia operacji transakcyjnych, uruchamia funkcję ZwCommitTransaction KTM. W tym momencie KTM powiadamia menedżera zasobów, że powinno trwale wykonać operacje. Następnie menedżer zasobów przenosi wyniki operacji ze strumienia dziennika do stałego nośnika magazynu danych. Na koniec menedżer zasobów wywołuje ZwCommitComplete, aby poinformować KTM, że operacja zatwierdzania została zakończona.

Co się stanie, jeśli menedżer zasobów zgłosi błąd podczas jednej z prób wywołania przez klienta ReadData lub WriteData? Klient może wywołać ZwRollbackTransaction, aby wycofać transakcję. W wyniku tego wywołania KTM powiadamia menedżera zasobów, że powinien przywrócić dane do stanu pierwotnego. Następnie klient może utworzyć nową transakcję dla tych samych operacji lub wybrać, że nie będzie kontynuować.

Poniższy pseudokod przedstawia przykład bardziej szczegółowej sekwencji operacji transakcyjnych 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 się stanie, jeśli system ulegnie awarii po utworzeniu transakcji, ale zanim zostanie zatwierdzony lub wycofany? Za każdym razem, gdy menedżer zasobów jest ładowany, powinien wywołać ZwRecoverTransactionManager i ZwRecoverResourceManager. Wywoływanie ZwRecoverTransactionManager powoduje, że KTM otwiera swój strumień dziennika i odczytuje historię transakcji. Wywołanie ZwRecoverResourceManager powoduje, że usługa KTM powiadamia menedżera zasobów o wszystkich transakcjach w toku przed awarią, które menedżer zasobów musi w związku z tym odzyskać.

Jeśli klient transakcyjny wywołał ZwCommitTransaction dla transakcji przed awarią i zaczął obsługiwać operacje zatwierdzania dla tej transakcji, menedżer zasobów musi mieć możliwość przywrócenia stanu transakcji do punktu bezpośrednio przed awarią. Jeśli klient nie był gotowy do zatwierdzenia transakcji przed awarią, menedżer zasobów może odrzucić dane i wycofać transakcję.

Aby uzyskać więcej informacji na temat pisania klientów transakcyjnych, zobacz Tworzenie klienta transakcyjnego.

Aby uzyskać więcej informacji na temat pisania menedżerów zasobów, zobacz Tworzenie menedżera zasobów.

Wielu zarządców zasobów w systemie TPS

Teraz załóżmy, że moduł TPS umożliwia klientom modyfikowanie informacji w dwóch oddzielnych bazach danych w ramach jednej transakcji, dzięki czemu transakcja powiedzie się tylko wtedy, gdy modyfikacje obu baz danych powiedzie się.

W takim przypadku moduł TPS może mieć dwa menedżery zasobów, po jednym dla każdej bazy danych. Każdy menedżer zasobów może wyeksportować interfejs API, którego klienci mogą używać do uzyskiwania dostępu do bazy danych usługi Resource Manager.

Poniższy pseudokod pokazuje, jak klient może utworzyć jedną transakcję zawierającą operacje na dwóch bazach danych, które obsługują dwa menedżery zasobów.

W tym przykładzie klient odczytuje dane z pierwszej bazy danych i zapisuje je w drugiej bazie danych. Następnie klient odczytuje dane z drugiej bazy danych i zapisuje je w pierwszej bazie danych. (Pierwszy menedżer zasobów eksportuje funkcje rozpoczynające się od Rm1, a drugi menedżer zasobów eksportuje funkcje rozpoczynające się 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;

Ponieważ klient przekazuje ten sam identyfikator transakcji do obu menedżerów zasobów, oba menedżery zasobów mogą wywoływać ZwOpenTransaction i ZwCreateEnlistment do rejestracji w transakcji. Gdy klient w końcu wywołuje funkcję ZwCommitTransaction, KTM powiadamia każdego menedżera zasobów, że powinien zatwierdzić operacje na stałe. Każdy menedżer zasobów wywołuje funkcję ZwCommitComplete po zakończeniu.

Inne scenariusze TPS

KTM obsługuje inne scenariusze TPS. Na przykład w następujących scenariuszach opisano składniki, które mogą zawierać moduł TPS:

  • Jeden menedżer zasobów, który zarządza wieloma bazami danych.

    Interfejs API menedżera zasobów może umożliwić klientom otwieranie i uzyskiwanie dostępu do więcej niż jednej bazy danych jednocześnie, a klient może łączyć dostęp do wielu baz danych w jednej transakcji.

  • Jeden menedżer zasobów z interfejsem API, który wywołują klienci, oraz pozostali menedżerowie zasobów z interfejsami API, które wywołuje pierwszy menedżer zasobów.

    Klient komunikuje się tylko z pierwszym menedżerem zasobów. Gdy menedżer zasobów przetwarza żądania od klienta, może uzyskać dostęp do dodatkowych menedżerów zasobów w razie potrzeby w celu przetworzenia żądań klienta. Na przykład menedżer zasobów zarządza bazą danych dostępną dla klienta, która wymaga operacji tworzenia kopii zapasowej lub weryfikacji danych z drugiego menedżera zasobów, do którego klienci nie mogą uzyskać dostępu.

  • Istniejący klient i menedżer zasobów, który nie używa KTM, zintegrowany z dodatkowym zestawem menedżerów zasobów korzystających z KTM.

    W takim przypadku zazwyczaj trzeba zmodyfikować istniejącego menedżera zasobów, aby stał się on lepszym menedżerem transakcji, który komunikuje się z KTM.

  • Last updated on