Elaborazione del ripristino

Dopo qualsiasi tipo di errore che interrompe la normale elaborazione delle transazioni, KTM e ogni resource manager devono eseguire operazioni di ripristino . Il ripristino è il processo in base al quale i partecipanti alle transazioni arrivano a una visualizzazione coerente dello stato di ogni transazione.

I responsabili delle risorse possono essere incerti sul risultato di una transazione, ovvero al momento dell'errore, hanno ricevuto una notifica di TRANSACTION_NOTIFY_PREPARE, aveva preparato l'archiviazione durevole, ma non aveva ricevuto (o ricevuto ma non registrato) un risultato finale per la transazione. Analogamente, KTM può essere in dubbio su una transazione se è stata preparata, ma non è stata ricevuta (o ricevuta ma non registrata) un risultato. In fase di ripristino, tutti i risultati inviati ma non riconosciuti devono essere re-inviati. Ad esempio, se un gestore risorse ha ricevuto una notifica TRANSACTION_NOTIFY_COMMIT e ha chiamato la funzione CommitComplete , l'RM può comunque ricevere una notifica duplicata TRANSACTION_NOTIFY_COMMIT in fase di ripristino.

Per ripristinare correttamente una transazione dopo un errore di gestione risorse o un errore di sistema, ogni resource manager deve eseguire le operazioni seguenti ogni volta che viene avviato:

1. Chiamare la funzione OpenResourceManager per riaprire l'handle di Gestione risorse usando il nome univoco e persistente. In questo modo KTM informa che il gestore risorse viene eseguito di nuovo ed è disponibile per eseguire il ripristino. Se non esiste alcun inserimento, la chiamata a OpenResourceManager può non riuscire. Chiamare CreateResourceManager per ricreare l'oggetto RM.

2. Chiamare RecoveryResourceManager. Gestione risorse riceverà un evento di notifica TRANSACTION_NOTIFY_RECOVER per ogni elenco per il quale deve eseguire operazioni di ripristino, seguite da un TRANSACTION_NOTIFY_LAST_RECOVER. L'evento di notifica include un identificatore univoco globale sia per la transazione che per l'inserimento.

3. Chiamare la funzione OpenEnlistment per riaprire ogni handle di inserimento per il quale gestione risorse ha ricevuto una notifica di TRANSACTION_NOTIFY_RECOVER.

4. Per ogni inserimento aperto da OpenEnlistment, chiamare RecoverEnlistment. Ciò causa la ridistribuitura della notifica TRANSACTION_NOTIFY_COMMIT o TRANSACTION_NOTIFY_INDOUBT.

5. Se rm ha ricevuto TRANSACTION_NOTIFY_COMMIT, rm può completare la transazione chiamando CommitComplete.

   Se rm ha ricevuto TRANSACTION_NOTIFY_INDOUBT, l'RM deve attendere l'arrivo della notifica del risultato.

6. Per tutte le transazioni per cui RM non riceve una notifica di TRANSACTION_NOTIFY_RECOVER, ma in precedenza ha ricevuto una notifica di TRANSACTION_NOTIFY_PREPARE per, l'RM deve elaborare la transazione come se fosse stato eseguito il rollback.

KTM usa un modello di transazione di interruzione presunto . Lo scenario seguente illustra questo comportamento. Si supponga che KTM e un gestore risorse esistano nello stesso computer. Si supponga che KTM problemi una notifica di preparazione per una transazione, ma il sistema si arresta in modo anomalo prima che KTM registri la notifica di preparazione. Si supponga inoltre che resource manager riceva e registri la notifica di preparazione appena prima che il sistema si arresta in modo anomalo. Dopo il ripristino del sistema, KTM non ha alcuna conoscenza della transazione, perché non ha mai registrato la fase di preparazione. Gestione risorse ha conoscenza della transazione, perché ha ricevuto, elaborato e registrato la notifica di preparazione. Quando KTM genera le notifiche di ripristino, il gestore risorse non include una notifica di ripristino per la transazione in questione. Con il modello di interruzione presunto, gestione risorse in questo caso considera la transazione preparata interrotta quando non riceve notifiche per eseguire il ripristino su tale transazione.