Informazioni sui componenti TPS

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 delle 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 risorse

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

• Uno o più flussi di log CLFS

  I gestori delle transazioni e i gestori delle risorse usano i 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ù clienti transazionali

  In genere, ogni client transazionale del 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 risorse, un tps più complesso che contiene più gestori 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 resource manager tramite un'interfaccia fornita da Resource Manager.

Si supponga, ad esempio, di voler creare un sistema di gestione di database. Si vuole che i client del sistema accingano 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 di voler eseguire set di operazioni di lettura e scrittura in modo atomico in modo che 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 di 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. Il gestore delle risorse può quindi partecipare alle transazioni.

È possibile che il gestore risorse 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 delle 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, il gestore delle risorse usa CLFS per registrare i risultati delle operazioni in un flusso del log delle transazioni.

Quando il client ha terminato di chiamare il gestore risorse per eseguire operazioni transazionali, chiama la routine ZwCommitTransaction di KTM. A questo punto, KTM notifica al gestore delle 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 invia una notifica al gestore risorse che deve ripristinare i dati nello 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 che venga eseguito 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 informi il gestore risorse di tutte le transazioni in corso prima dell'arresto anomalo e quali transazioni il gestore risorse deve quindi recuperare.

Se un client transazionale ha invocato ZwCommitTransaction per una transazione prima del crash e ha iniziato a gestire le operazioni di commit per la transazione, il gestore delle risorse deve essere in grado di ripristinare lo stato della transazione al punto immediatamente precedente al crash. Se il client non era pronto a convalidare la transazione prima dell'arresto anomalo, il gestore delle risorse può eliminare i dati e ripristinare la transazione.

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

Per altre informazioni su come scrivere i gestori 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 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 contenente 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 funzioni che iniziano con Rm1 e la seconda resource manager 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 infine chiama ZwCommitTransaction, KTM notifica a ogni gestore risorse che il gestore risorse deve rendere permanenti le operazioni, e ogni gestore risorse chiama ZwCommitComplete quando ha terminato.

Altri scenari TPS

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

• Uno strumento di gestione 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 gestione risorse elabora le richieste da un client, può accedere agli strumenti di gestione 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.