Delen via

Begrip van TPS-onderdelen

Elk transactieverwerkingssysteem (TPS) dat gebruikmaakt van de Kernel Transaction Manager (KTM) en het Common Log File System (CLFS) moet de volgende belangrijke onderdelen bevatten:

  • Een transactiemanager (KTM)

    KTM houdt de status van elke transactie bij en coördineert herstelbewerkingen na een systeemcrash.

  • Een of meer resourcemanagers

    Resourcemanagers die u verstrekt, beheren de gegevens die aan elke transactie zijn gekoppeld.

  • Een of meer CLFS-logboekstreams

    De transaction manager en resourcemanagers gebruiken CLFS-logboekstromen om informatie vast te leggen die ze kunnen gebruiken om een transactie vast te leggen, terug te draaien of te herstellen.

  • Een of meer transactionele cliënten

    Normaal gesproken kan elke transactionele client van uw TPS een transactie maken, bewerkingen uitvoeren op gegevens binnen de context van de transactie en vervolgens een doorvoer- of terugdraaibewerking voor de transactie initiëren.

In dit artikel maakt u kennis met een eenvoudige TPS met één resourcemanager, een complexere TPS die meerdere resourcemanagers bevat en enkele andere TPS-scenario's.

De sectie KTM gebruiken bevat gedetailleerde informatie over het gebruik van KTM om TPS-onderdelen te maken.

Eenvoudige TPS

Een eenvoudige TPS kan bestaan uit KTM, één resourcemanager en CLFS. Transactionele clients kunnen communiceren met de resourcemanager via een interface die de resourcemanager biedt.

Stel dat u een databasebeheersysteem wilt maken. U wilt dat de clients van uw systeem toegang hebben tot de database door een ingang te openen voor een databaseobject, lees- en schrijfbewerkingen uit te voeren op het object en vervolgens de objectgreep te sluiten.

Stel nu dat u wilt dat sets lees- en schrijfbewerkingen atomisch worden uitgevoerd, zodat andere gebruikers van het systeem alleen het uiteindelijke resultaat zien. U kunt dat doel bereiken door een TPS te ontwerpen waarmee clients sets databasebewerkingen kunnen binden aan een transactie.

Uw systeem moet een resourcemanager bevatten die de gegevens in de database beheert als reactie op het lezen en schrijven van aanvragen van clients. Deze Resource Manager kan een API (Application Programming Interface) exporteren waarmee clients een transactie kunnen koppelen aan een set lees- en schrijfbewerkingen.

Wanneer u uw resourcemanager laadt, moet deze zich registreren bij KTM door ZwCreateTransactionManager en ZwCreateResourceManager aan te roepen. Vervolgens kan de Resource Manager deelnemen aan transacties.

Mogelijk wilt u uw Resource Manager ondersteuning bieden voor een set functies waarmee clients gegevensobjecten kunnen maken, gegevens kunnen lezen en schrijven die aan de gegevensobjecten zijn gekoppeld en de gegevensobjecten kunnen sluiten. De volgende pseudocode toont een voorbeeldcodereeks van een 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);

Voordat een client de CreateDataObject-routine van uw resourcemanager kan aanroepen, moet de client een transactieobject maken door de ZwCreateTransaction-routine van KTM aan te roepen en de id van het transactieobject op te halen door ZwQueryInformationTransaction aan te roepen.

Wanneer de client de CreateDataObject-routine van uw resourcemanager aanroept, geeft de client de id van het transactieobject door aan de resourcemanager. De resourcemanager kan ZwOpenTransaction aanroepen om een ingang voor het transactieobject te verkrijgen en vervolgens ZwCreateEnlistment aanroepen om de deelname aan de transactie te registreren.

Op dit moment kan de client beginnen met het uitvoeren van bewerkingen op het gegevensobject. Omdat de client een transactie-id heeft opgegeven bij het maken van het gegevensobject, kan de resourcemanager alle lees- en schrijfbewerkingen toewijzen aan de transactie.

Uw resourcemanager moet alle resultaten van gegevensbewerkingen vastleggen die de client opgeeft zonder de resultaten permanent te maken. Normaal gesproken gebruikt resourcemanager CLFS om de bewerking vast te leggen in een transactielogboekstroom.

Wanneer de client klaar is met het aanroepen van de resourcemanager om transactionele bewerkingen uit te voeren, wordt de ZwCommitTransaction-routine van KTM aangeroepen. Op dit moment informeert KTM de resourcemanager dat hij de bewerkingen permanent moet maken. De resourcemanager verplaatst vervolgens de bewerkingsresultaten van de logboekstroom naar het permanente opslagmedium van de gegevens. Ten slotte roept de resourcemanager ZwCommitComplete aan om KTM te informeren dat de doorvoerbewerking is voltooid.

Wat gebeurt er als uw Resource Manager een fout rapporteert voor een van de aanroepen van de client naar ReadData of WriteData? De client kan ZwRollbackTransaction aanroepen om de transactie terug te draaien. Als gevolg van deze aanroep geeft KTM de resourcemanager een bericht dat de gegevens moeten worden hersteld naar de oorspronkelijke staat. Vervolgens kan de client een nieuwe transactie voor dezelfde bewerkingen maken of ervoor kiezen om niet door te gaan.

De volgende pseudocode toont een voorbeeld van een meer gedetailleerde reeks transactionele bewerkingen van een client.

    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;

Wat gebeurt er als het systeem vastloopt nadat de transactie is gemaakt, maar voordat deze wordt doorgevoerd of teruggedraaid? Telkens wanneer uw resourcemanager wordt geladen, moet zwRecoverTransactionManager en ZwRecoverResourceManager worden aangeroepen. Door ZwRecoverTransactionManager aan te roepen, opent KTM de logboekstream en leest u de transactiegeschiedenis. Door ZwRecoverResourceManager aan te roepen, geeft KTM een melding van alle in de lijst opgenomen transacties die vóór de crash werden uitgevoerd en welke transacties de resourcemanager moet herstellen.

Als een transactionele client ZwCommitTransaction op een transactie aanriep vóór de crash en begon met het verwerken van de commitbewerkingen voor de transactie, moet de resourcemanager in staat zijn de staat van de transactie te herstellen naar vlak voor de crash. Als de client nog niet klaar was om de transactie door te voeren vóór het vastlopen, kan de resourcemanager de gegevens verwijderen en de transactie terugdraaien.

Voor meer informatie over het schrijven van transactionele clients, zie Een transactionele client maken.

Zie Een Resource Manager maken voor meer informatie over het schrijven van resourcemanagers.

Meerdere resourcemanagers in een TPS

Stel nu dat uw TPS clients in staat stelt om informatie in twee afzonderlijke databases binnen één transactie te wijzigen, zodat de transactie alleen slaagt als de wijzigingen van beide databases slagen.

In dit geval kan uw TPS twee resourcemanagers hebben, één voor elke database. Elke Resource Manager kan een API exporteren die clients kunnen gebruiken om toegang te krijgen tot de database van Resource Manager.

De volgende pseudocode laat zien hoe een client één transactie kan maken die bewerkingen bevat op twee databases die door twee resourcemanagers worden ondersteund.

In dit voorbeeld leest de client gegevens uit de eerste database en schrijft deze naar de tweede database. Vervolgens leest de client gegevens uit de tweede database en schrijft deze naar de eerste database. (De eerste resourcemanager exporteert functies die beginnen met Rm1 en de tweede resourcemanager exporteert functies die beginnen met 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;

Omdat de client dezelfde transactie-id doorgeeft aan beide resourcemanagers, kunnen beide resourcemanagers ZwOpenTransaction en ZwCreateEnlistment aanroepen om in de transactie in te schakelen. Wanneer de client uiteindelijk ZwCommitTransactionaanroept , meldt KTM elke resourcemanager dat de manager de bewerkingen permanent moet maken en roept elke resourcemanager ZwCommitComplete aan wanneer deze is voltooid.

Andere TPS-scenario's

KTM ondersteunt andere TPS-scenario's. In de volgende scenario's worden bijvoorbeeld onderdelen beschreven die een TPS kan bevatten:

  • Eén resourcemanager die meerdere databases beheert.

    Met de API van de resourcebeheerder kunnen clienttoepassingen meer dan één database tegelijkertijd openen en benaderen. De client kan toegang tot meerdere databases in één transactie combineren.

  • Eén resourcemanager met een API die clients aanroepen en andere resourcemanagers met API's die de eerste resource manager aanroept.

    De client communiceert alleen met de eerste resourcemanager. Wanneer die Resource Manager aanvragen van een client verwerkt, heeft deze, indien nodig, toegang tot de extra resourcemanagers om de aanvragen van de client te verwerken. Een resourcemanager beheert bijvoorbeeld een client toegankelijke database waarvoor back-up- of gegevensverificatiebewerkingen zijn vereist vanuit een tweede resourcemanager waartoe clients geen toegang hebben.

  • Een bestaande client en resourcemanager die geen KTM gebruiken, geïntegreerd met een extra set resourcemanagers die gebruikmaken van KTM.

    In dit geval moet u doorgaans de bestaande resourcemanager wijzigen, zodat deze een superieure transactiemanager wordt die communiceert met KTM.

  • Last updated on