Gestione delle operazioni di commit

Esistono due tipi di operazioni di commit: commit a singola fase e commit in più fasi. Un'operazione di commit a singola fase è costituita da una singola notifica a cui i responsabili delle risorse devono rispondere, mentre un'operazione di commit in più fasi include notifiche aggiuntive per i passaggi di preparazione.

Un'operazione di commit a singola fase è più semplice da implementare. È appropriato per i sistemi di elaborazione delle transazioni (TPS) con una delle caratteristiche seguenti:

• Un singolo gestore di risorse.

• Più gestori di risorse, tutti tranne uno dei quali sono di sola lettura e non partecipano all'operazione di commit.

Un'operazione di commit in più fasi è necessaria se più gestori di risorse partecipano all'operazione di commit.

Single-Phase Operazioni di Commit

Se si vuole che il TPS supporti le operazioni di commit a fase singola, un gestore delle risorse (e solo uno) deve registrarsi per ricevere notifiche di TRANSACTION_NOTIFY_SINGLE_PHASE_COMMIT per i relativi arruolamenti. Tutti gli altri gestori di risorse devono essere di sola lettura.

Un TPS che include un gestore di transazioni superiore non può usare il commit a fase singola.

Se un gestore di risorse si è registrato per ricevere le notifiche TRANSACTION_NOTIFY_SINGLE_PHASE_COMMIT, KTM invia questo tipo di notifica quando un client transazionale chiama ZwCommitTransaction.

Quando il gestore risorse riceve una notifica di TRANSACTION_NOTIFY_SINGLE_PHASE_COMMIT per una transazione, può eseguire il commit della transazione o rifiutare il commit in una singola fase.

Per eseguire il commit della transazione, resource manager deve eseguire le operazioni seguenti:

1. Svuotare tutti i dati che si trovano in una cache non permanente (memoria volatile), ad esempio nell'area di marshalling CLFS per un flusso di log CLFS.

   Resource Manager deve spostare i dati dalla cache a un supporto di archiviazione durevole. Ad esempio, un gestore di risorse che usa CLFS può chiamare ClfsFlushBuffers.

2. Rendere permanenti e pubbliche tutte le modifiche ai dati, ovvero visibili all'esterno dell'ambito di Resource Manager.

3. Chiama ZwCommitComplete.

Dopo aver chiamato ZwCommitComplete, il gestore delle risorse deve chiamare ZwClose per chiudere l'handle di integrazione.

Per rifiutare un'operazione di commit a singola fase per la transazione, il gestore delle risorse può chiamare ZwSinglePhaseReject. Se il gestore delle risorse chiama ZwSinglePhaseReject, KTM modifica immediatamente l'operazione di commit da una singola fase a più fasi.

Se altri gestori di risorse partecipano alla stessa transazione, devono essere di sola lettura. Tuttavia, devono registrarsi per ricevere la notifica di TRANSACTION_NOTIFY_RM_DISCONNECTED, che ricevono se il gestore risorse che gestisce l'operazione di commit a fase singola chiude l'handle di integrazione senza indicare che è stato eseguito il commit o il rollback della transazione.

Operazioni di commit in più fasi

Un'operazione di commit in più fasi inizia quando si verifica uno degli eventi seguenti:

• Un client transazionale chiama ZwCommitTransaction e nessun gestore di risorse è registrato per ricevere notifiche di TRANSACTION_NOTIFY_SINGLE_PHASE_COMMIT.

• Un gestore di risorse chiama ZwSinglePhaseReject dopo aver ricevuto una notifica di TRANSACTION_NOTIFY_SINGLE_PHASE_COMMIT.

• Un gestore transazioni superiore chiama ZwPrePrepareEnlistment.

Le operazioni di commit in più fasi sono costituite da tre fasi sequenziali: pre-preparazione, preparazione e commit.

Fase di pre-preparazione

La fase di pre-preparazione (nota anche come fase zero) dell'operazione di commit inizia quando KTM invia una notifica di TRANSACTION_NOTIFY_PREPREPARE a tutti i gestori risorse. KTM invia questa notifica se nessun gestore di risorse supporta un'operazione di commit a fase singola per la transazione o se un gestore transazioni superiore chiama ZwPreprepareEnlistment.

Quando ogni resource manager riceve la notifica di TRANSACTION_NOTIFY_PREPREPARE, deve eseguire le operazioni seguenti:

1. Scarica tutti i dati che si trovano in una cache non permanente (archiviazione in memoria), come l'area di marshalling CLFS per un flusso di log CLFS.

   Resource Manager deve spostare i dati dalla cache a un supporto di archiviazione durevole. Ad esempio, un gestore di risorse che usa CLFS può chiamare ClfsFlushBuffers.

2. Chiama ZwPrePrepareComplete.

Dopo che un resource manager ha chiamato ZwPreprepareComplete, può continuare a ricevere e gestire le richieste client. Tuttavia, il gestore delle risorse deve considerare tutte le modifiche ai dati come operazioni dirette della cache che vengono scritte immediatamente su un supporto di archiviazione durevole.

Se un gestore di risorse rileva un errore durante l'elaborazione di una notifica di TRANSACTION_NOTIFY_PREPREPARE, deve chiamare ZwRollbackEnlistment per eseguire il rollback della transazione.

Fase di preparazione

La fase di preparazione (nota anche come fase 1) dell'operazione di commit inizia quando KTM invia una notifica di TRANSACTION_NOTIFY_PREPARE a tutti i gestori risorse. KTM invia questa notifica dopo TRANSACTION_NOTIFY_PREPREPARE se nessun gestore di risorse supporta il commit a singola fase o se un gestore transazioni superiore chiama ZwPrepareEnlistment.

Quando ogni resource manager riceve la notifica di TRANSACTION_NOTIFY_PREPARE, deve eseguire le operazioni seguenti:

1. Interrompere il servizio delle richieste client e segnalare eventuali richieste successive come errori del client.

2. Assicurarsi che tutti i dati siano stati spostati in una risorsa di archiviazione durevole.

3. Chiama ZwPrepareComplete.

Se un gestore risorse rileva un errore durante l'elaborazione di una notifica di TRANSACTION_NOTIFY_PREPARE, deve chiamare ZwRollbackEnlistment per eseguire il rollback della transazione. Tuttavia, il gestore risorse non può eseguire il rollback della transazione dopo che ha chiamato ZwPrepareComplete.

Fase di commit

La fase di commit (nota anche come fase due) dell'operazione di commit inizia quando KTM invia una notifica di TRANSACTION_NOTIFY_COMMIT a tutti i gestori risorse. KTM invia questa notifica dopo TRANSACTION_NOTIFY_PREPARE se nessun gestore di risorse supporta il commit a singola fase o se un gestore transazioni superiore chiama ZwCommitEnlistment.

Quando ogni resource manager riceve la notifica di TRANSACTION_NOTIFY_COMMIT, deve eseguire le operazioni seguenti:

1. Rendere permanenti e pubbliche tutte le modifiche ai dati, ovvero visibili ad altre transazioni.

   In genere, un gestore di risorse apporta modifiche permanenti e pubbliche copiando i dati salvati della transazione dal flusso di log all'archiviazione pubblica e permanente del database. Per altre informazioni sull'uso dei flussi di log, vedere Uso di flussi di log con KTM.

2. Chiama ZwCommitComplete.

Dopo che il gestore delle risorse chiama ZwCommitComplete, deve chiamare ZwClose per chiudere l'handle di integrazione.

Se un gestore delle risorse rileva un errore durante l'elaborazione di una notifica di TRANSACTION_NOTIFY_COMMIT, dovrebbe arrestarsi. La volta successiva che il sistema operativo ricarica il gestore risorse, il processo di ripristino di Resource Manager deve ripristinare la transazione in uno stato noto per essere valido prima che si sia verificato l'errore.