Gestione delle operazioni di commit

  • Articolo

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

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

  • Un singolo resource manager.

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

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

operazioni di commit Single-Phase

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

Un TPS che include un gestore transazioni superiore non può usare il commit a più fasi.

Se un gestore risorse ha registrato per ricevere notifiche TRANSACTION_NOTIFY_SINGLE_PHASE_COMMIT, KTM invia questa notifica quando un client transazionale chiama ZwCommitTransaction.

Quando gestione risorse riceve una notifica di TRANSACTION_NOTIFY_SINGLE_PHASE_COMMIT per una transazione, può eseguire il commit della transazione o rifiutare il commit a più fasi.

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

  1. Scaricare tutti i dati che contiene in una cache non permanente (archiviazione in memoria), ad esempio l'area di marshalling CLFS per un flusso di log CLFS.

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

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

  3. Chiama ZwCommitComplete.

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

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

Se altri gestori di risorse vengono inseriti nella stessa transazione, devono essere di sola lettura. Tuttavia, devono registrarsi per ricevere la notifica di TRANSACTION_NOTIFY_RM_DISCONNECTED, che ricevono se Gestione risorse che gestisce l'operazione di commit a fase singola chiude l'handle di inserimento senza indicare che ha eseguito il commit o il rollback della transazione.

Operazioni di commit a più fasi

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

Le operazioni di commit a 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 responsabili delle risorse. KTM invia questa notifica se nessun gestore risorse supporta un'operazione di commit a fase singola per la transazione o se un gestore transazioni superiore chiama ZwPrepareEnlistment.

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

  1. Scaricare tutti i dati che contiene in una cache non permanente (archiviazione in memoria), ad esempio l'area di marshalling CLFS per un flusso di log CLFS.

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

  2. Chiamare ZwPrepareComplete.

Dopo che un resource manager ha chiamato ZwPreprepareComplete, può continuare a ricevere e gestire le richieste client. Tuttavia, resource manager deve considerare tutte le modifiche ai dati come operazioni pass-through della cache scritte immediatamente in un supporto di archiviazione durevole.

Se un gestore 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 uno) dell'operazione di commit inizia quando KTM invia una notifica di TRANSACTION_NOTIFY_PREPARE a tutti i responsabili delle risorse. KTM invia questa notifica dopo TRANSACTION_NOTIFY_PREPREPARE se nessun gestore risorse supporta il commit a fase singola o se un gestore di transazioni superiore chiama ZwPrepareEnlistment.

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

  1. Arrestare le richieste client di manutenzione e segnalare le richieste successive del client come errori client.

  2. Assicurarsi che tutti i dati siano stati spostati nell'archiviazione durevole.

  3. Chiamare 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, resource manager non può eseguire il rollback della transazione dopo aver 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 responsabili delle risorse. KTM invia questa notifica dopo TRANSACTION_NOTIFY_PREPARE se nessun gestore risorse supporta il commit a fase singola 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. Apportare tutte le modifiche ai dati permanenti e pubbliche, ovvero visibili ad altre transazioni.

    In genere, un gestore risorse apporta modifiche permanenti e pubbliche copiando i dati salvati dalla 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 risorse chiama ZwCommitComplete, deve chiamare ZwClose per chiudere l'handle di inserimento.

Se un gestore risorse rileva un errore durante l'elaborazione di una notifica di TRANSACTION_NOTIFY_COMMIT, deve 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 prima dell'errore.