Condividi tramite

Informazioni sui componenti TPS

  • Articolo

Qualsiasi sistema di elaborazione delle transazioni (TPS) che usa Kernel Transaction Manager (KTM) e Common Log File System (CLFS) deve contenere i componenti importanti seguenti:

  • Gestore transazioni (KTM)

    KTM tiene traccia dello stato di ogni transazione e coordina le operazioni di ripristino dopo un arresto anomalo del sistema.

  • Uno o più gestori di risorse

    I gestori di risorse, forniti dall'utente, gestiscono i dati associati a ogni transazione.

  • Uno o più flussi di log CLFS

    Gestione transazioni e gestori risorse usano flussi di log CLFS per registrare informazioni che possono essere usate per eseguire il commit, il rollback o il ripristino di una transazione.

  • Uno o più client transazionali

    In genere, ogni client transazionale di TPS può creare una transazione, eseguire operazioni sui dati all'interno del contesto della transazione e quindi avviare un'operazione di commit o rollback per la transazione.

Questo argomento presenta un semplice tps con un gestore di risorse, un tps più complesso che contiene più gestori di risorse e altri scenari TPS.

La sezione Using KTM fornisce informazioni dettagliate su come usare KTM per creare componenti TPS.

TPS semplice

Un semplice TPS può essere costituito da KTM, un gestore di risorse e CLFS. I client transazionali possono comunicare con gestione risorse tramite un'interfaccia fornita da Resource Manager.

Si supponga, ad esempio, di voler creare un sistema di gestione di database. I client del sistema devono accedere al database aprendo un handle a un oggetto di database, eseguendo operazioni di lettura e scrittura sull'oggetto e quindi chiudendo l'handle dell'oggetto.

Si supponga ora che si desideri che i set di operazioni di lettura e scrittura si verifichino in modo atomico in modo che gli altri utenti del sistema visualizzino solo il risultato finale. È possibile raggiungere tale obiettivo progettando un tps che consente ai client di associare set di operazioni di database a una transazione.

Il sistema deve includere un gestore risorse che gestisce i dati nel database in risposta alle richieste di lettura e scrittura dai client. Questo gestore di risorse potrebbe esportare un'API (Application Programming Interface) che consente ai client di associare una transazione a un set di operazioni di lettura e scrittura.

Quando il gestore risorse viene caricato, deve registrarsi con KTM chiamando ZwCreateTransactionManager e ZwCreateResourceManager. Quindi, resource manager può partecipare alle transazioni.

È possibile che resource manager supporti un set di funzioni che consenta ai client di creare oggetti dati, leggere e scrivere dati associati agli oggetti dati e chiudere gli oggetti dati. Lo pseudocodice seguente mostra una sequenza di codice di esempio da un 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);

Prima che un client possa chiamare la routine CreateDataObject del gestore risorse, il client deve creare un oggetto transazione chiamando la routine ZwCreateTransaction di KTM e ottenere l'identificatore dell'oggetto transazione chiamando ZwQueryInformationTransaction.

Quando il client chiama la routine CreateDataObject del gestore risorse, il client passa l'identificatore dell'oggetto transazione al gestore risorse. Il gestore risorse può chiamare ZwOpenTransaction per ottenere un handle per l'oggetto transazione e quindi può chiamare ZwCreateEnlistment per registrare la partecipazione alla transazione.

A questo punto, il client può iniziare a eseguire operazioni sull'oggetto dati. Poiché il client ha fornito un identificatore di transazione quando ha creato l'oggetto dati, gestione risorse può assegnare tutte le operazioni di lettura e scrittura alla transazione.

Il gestore delle risorse deve registrare tutti i risultati delle operazioni sui dati specificate dal client senza rendere permanenti i risultati. In genere, resource manager usa CLFS per registrare i risultati dell'operazione in un flusso di log delle transazioni.

Al termine della chiamata del client a Resource Manager per eseguire operazioni transazionali, il client chiama la routine ZwCommitTransaction di KTM. A questo punto, KTM notifica al gestore risorse che deve rendere permanenti le operazioni. Gestione risorse sposta quindi i risultati dell'operazione dal flusso di log al supporto di archiviazione permanente dei dati. Infine, il gestore delle risorse chiama ZwCommitComplete per informare KTM che l'operazione di commit è stata completata.

Cosa accade se resource manager segnala un errore per una delle chiamate del client a ReadData o WriteData? Il client può chiamare ZwRollbackTransaction per eseguire il rollback della transazione. In seguito a tale chiamata, KTM notifica al gestore risorse che deve ripristinare i dati allo stato originale. Il client può quindi creare una nuova transazione per le stesse operazioni oppure scegliere di non continuare.

Lo pseudocodice seguente mostra un esempio di una sequenza più dettagliata delle operazioni transazionali di un 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;

Cosa accade se il sistema si arresta in modo anomalo dopo la creazione della transazione, ma prima di eseguire il commit o il rollback? Ogni volta che il gestore risorse viene caricato, deve chiamare ZwRecoverTransactionManager e ZwRecoverResourceManager. Chiamando ZwRecoverTransactionManager , KTM apre il flusso di log e legge la cronologia delle transazioni. La chiamata a ZwRecoverResourceManager fa sì che KTM comunicherà al gestore risorse tutte le transazioni in corso prima dell'arresto anomalo e le transazioni che devono quindi essere ripristinate dal gestore risorse.

Se un client transazionale denominato ZwCommitTransaction per una transazione prima dell'arresto anomalo e ha iniziato a gestire le operazioni di commit per la transazione, il gestore risorse deve essere in grado di ripristinare lo stato della transazione immediatamente prima dell'arresto anomalo. Se il client non è pronto per eseguire il commit della transazione prima dell'arresto anomalo, gestione risorse può eliminare i dati ed eseguire il rollback della transazione.

Per altre informazioni su come scrivere client transazionali, vedere Creazione di un client transazionale.

Per altre informazioni su come scrivere i gestori di risorse, vedere Creazione di un Resource Manager.

Più gestori di risorse in un tps

Si supponga ora che il tps consenta ai client di modificare le informazioni in due database separati all'interno di una singola transazione, in modo che la transazione abbia esito positivo solo se le modifiche di entrambi i database hanno esito positivo.

In questo caso, il tps può avere due gestori di risorse, uno per ogni database. Ogni resource manager può esportare un'API che i client possono usare per accedere al database di Resource Manager.

Lo pseudocodice seguente illustra come un client potrebbe creare una singola transazione che contiene operazioni su due database supportati da due gestori risorse.

In questo esempio il client legge i dati dal primo database e lo scrive nel secondo database. Il client legge quindi i dati dal secondo database e lo scrive nel primo database. Il primo resource manager esporta le funzioni che iniziano con Rm1 e la seconda gestione risorse esporta funzioni che iniziano con 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;

Poiché il client passa lo stesso identificatore di transazione a entrambi i gestori risorse, entrambi i gestori di risorse possono chiamare ZwOpenTransaction e ZwCreateEnlistment per l'integrazione nella transazione. Quando il client chiama infine ZwCommitTransaction, KTM notifica a ogni gestore risorse che il manager deve rendere permanenti le operazioni e ogni gestore di risorse chiama ZwCommitComplete al termine dell'operazione.

Altri scenari TPS

KTM supporta altri scenari TPS. Ad esempio, gli scenari seguenti descrivono i componenti che un TPS può contenere:

  • Uno strumento di gestione delle risorse che gestisce più database.

    L'API di Resource Manager potrebbe consentire ai client di aprire e accedere a più database alla volta e il client potrebbe combinare gli accessi a più database in una singola transazione.

  • Un gestore di risorse con un'API che i client chiamano e altri gestori di risorse con API chiamate dal primo resource manager.

    Il client comunica solo con il primo resource manager. Quando resource manager elabora le richieste da un client, può accedere ai gestori di risorse aggiuntivi, in base alle esigenze, per elaborare le richieste del client. Ad esempio, un gestore di risorse gestisce un database accessibile dal client che richiede operazioni di backup o verifica dei dati da un secondo gestore risorse non disponibile per i client.

  • Un client esistente e un gestore risorse che non usano KTM, integrati con un set aggiuntivo di gestori di risorse che usano KTM.

    In questo caso, in genere è necessario modificare il gestore risorse esistente in modo che diventi un gestore transazioni superiore che comunica con KTM.