Nota
L'accesso a questa pagina richiede l'autorizzazione. Puoi provare ad accedere o a cambiare directory.
L'accesso a questa pagina richiede l'autorizzazione. Puoi provare a cambiare directory.
I gestori delle risorse gestiscono i dati di ogni transazione e registrano le operazioni della transazione. Se un sistema di elaborazione delle transazioni (TPS) dispone di più gestori risorse, ogni gestore di risorse può partecipare alle operazioni di commit, rollback e ripristino di ogni transazione.
Ogni resource manager deve esportare un'interfaccia che i client transazionali possono usare per accedere al database o a un'altra risorsa gestita da Resource Manager.
In genere, un gestore risorse in modalità kernel deve eseguire le attività seguenti nell'ordine elencato:
Creare un flusso di log.
I gestori di risorse possono usare common log file system (CLFS) o altre funzionalità di registrazione per gestire i flussi di log. Una chiamata a ClfsCreateLogFile crea un flusso di log CLFS. Gestione risorse deve usare il flusso di log per registrare tutte le informazioni necessarie per eseguire il commit, il rollback o il ripristino delle transazioni. KTM usa inoltre il flusso di log per registrare eventuali modifiche di stato interne che potrebbero essere necessarie per recuperare le transazioni.
Creare un oggetto di gestione transazioni.
Una chiamata a ZwCreateTransactionManager crea un oggetto di gestione transazioni e connette il gestore delle risorse a un flusso di log CLFS aggiuntivo specificato da Resource Manager.
Ripristinare lo stato di gestione transazioni.
Una chiamata a ZwRecoverTransactionManager legge il flusso di log dell'oggetto di gestione transazioni (gestito da KTM) e determina se il tps è stato arrestato prima del completamento di tutte le transazioni, ad esempio perché il sistema si è arrestato in modo anomalo. KTM ripristina lo stato interno in base alle informazioni nel flusso di log.
Creare un oggetto gestore delle risorse.
Una chiamata a ZwCreateResourceManager crea un oggetto resource manager e lo associa all'oggetto di gestione transazioni creato in precedenza.
Ripristinare lo stato di Resource Manager.
Una chiamata a ZwRecoverResourceManager fa sì che KTM invii le notifiche di gestione risorse TRANSACTION_NOTIFY_RECOVER per tutte le transazioni in corso l'ultima volta che il gestore risorse si arresta. Per informazioni su come il gestore risorse deve rispondere a queste notifiche, vedere Gestione delle operazioni di ripristino.
Ricevere transazioni dai client.
In genere, un client crea un oggetto transazione e usa l'interfaccia client di Resource Manager per passare il GUID dell'oggetto transazione al gestore risorse. Ad esempio, il gestore delle risorse potrebbe fornire una routine CreateDataObject, simile a quella descritta nell'argomento Comprendere i componenti TPS.
Iscriversi a ogni transazione.
Una chiamata a ZwOpenTransaction apre un handle all'oggetto transazione e quindi una chiamata a ZwCreateEnlistment crea un'iscrizione per la transazione. La registrazione consente al gestore delle risorse di ricevere un set specifico di notifiche di transazione .
Abilitare la ricezione delle notifiche delle transazioni.
Il gestore delle risorse può chiamare ZwGetNotificationResourceManager per ottenere le notifiche in modo sincrono oppure può chiamare TmEnableCallbacks per registrare un ResourceManagerNotification routine di callback che KTM chiama ogni volta che è disponibile una notifica.
I client inviano richieste di accesso alle risorse del servizio, ma le modifiche non devono essere rese permanenti.
Dopo che un client ha creato un oggetto transazione, in genere chiama l'interfaccia di Resource Manager per accedere alla risorsa di Resource Manager. Ad esempio, un gestore risorse per un database potrebbe ricevere richieste di lettura e scrittura nel database.
Il gestore risorse deve registrare i risultati delle operazioni di lettura e scrittura in un flusso di log CLFS o altre funzionalità di registrazione fino a quando non riceve una notifica che le operazioni della transazione verranno sottoposte a commit, rollback o ripristino.
Eseguire il commit o il rollback delle operazioni client.
Alla fine, il gestore delle risorse riceve una notifica per iniziare a compiere il commit o il rollback delle operazioni effettuate dal client. In risposta, il resource manager deve rendere permanenti le operazioni del client o scartarle. Per altre informazioni su come gestire le notifiche di commit e rollback, vedere Gestione delle operazioni delle transazioni.
In alcuni casi, un resource manager potrebbe dover tentare di forzare KTM a fornire rapidamente una notifica di commit o rollback, forse perché il gestore delle risorse ha determinato che un dispositivo è stato rimosso a sorpresa. In tal caso, il resource manager può chiamare TmRequestOutcomeEnlistment.
Chiudere l'handle dell'oggetto di integrazione.
Al termine dell'elaborazione della transazione, il gestore delle risorse deve chiamare ZwClose per chiudere l'handle dell'oggetto di integrazione
Chiudere l'handle dell'oggetto resource manager e l'handle dell'oggetto di gestione transazioni.
Prima che venga scaricato, il gestore delle risorse deve chiamare ZwClose per chiudere l'handle dell'oggetto gestore delle risorse e l'handle dell'oggetto gestore delle transazioni.
I passaggi da 1 a 5 devono essere eseguiti nel codice di inizializzazione di Resource Manager. Ad esempio, se il resource manager è un driver in modalità kernel, il codice di inizializzazione è la routine DriverEntry del driver.
I passaggi da 6 a 11 vengono in genere eseguiti nel codice che risponde alle richieste dai client transazionali.
Il passaggio 12 deve essere eseguito nel codice di pulizia finale del Resource Manager, ad esempio nella routine di scarico di un driver in modalità kernel.
Creazione di un'arruolamento di Read-Only
Un 'integrazione di sola lettura è un'integrazione che non riceve alcuna notifica da KTM. Un gestore risorse può rendere qualsiasi iscrizione di sola lettura chiamando ZwReadOnlyEnlistment. Questa chiamata causa l'interruzione del recapito delle notifiche al gestore risorse da parte di KTM.
Dopo che il gestore risorse ha chiamato ZwCreateEnlistment, può chiamare ZwReadOnlyEnlistment in qualsiasi momento fino al punto in cui normalmente chiamerebbe ZwPrepareComplete.
Esistono due motivi per cui è possibile che il gestore delle risorse chiami ZwReadOnlyEnlistment.
Il gestore risorse ha partecipato a una transazione e, a un certo punto, prima di ricevere una notifica di TRANSACTION_NOTIFY_COMMIT, il gestore delle risorse determina che non deve più partecipare all'operazione di commit della transazione.
Ad esempio, quando resource manager riceve una notifica di TRANSACTION_NOTIFY_PREPARE, potrebbe determinare che nessuna delle operazioni della transazione ha modificato il database del gestore risorse. Il gestore delle risorse può chiamare ZwReadOnlyEnlistment anziché ZwPrepareComplete per rimuoverlo dalla transazione.
Il gestore risorse non partecipa mai all'operazione di commit di alcuna transazione.
Ad esempio, resource manager potrebbe monitorare i dati inviati dal client, senza modificare alcun database archiviato. In questo caso, il gestore delle risorse potrebbe chiamare ZwReadOnlyEnlistment immediatamente dopo aver chiamato ZwCreateEnlistment. Inoltre, è possibile scegliere di creare un gestore di risorse di questo tipo volatile, come descritto nella sezione successiva di questo argomento.
Dopo che un gestore di risorse ha chiamato ZwReadOnlyEnlistment, può chiamare ZwClose per chiudere l'handle di adesione.
Creazione di un Volatile-Resource Manager
Un volatile-resource manager è un gestore risorse che non gestisce dati durevoli. Ad esempio, è possibile creare un gestore di risorse volatile per monitorare i dati inviati dal client, se resource manager non modifica un database archiviato in modo permanente. I gestori di risorse volatili in genere non registrano l'attività delle transazioni e pertanto non possono eseguire operazioni di ripristino o rollback.
Un gestore di risorse volatile deve impostare il flag di RESOURCE_MANAGER_VOLATILE quando chiama ZwCreateResourceManager. Se questo flag è impostato, KTM non registra alcuna informazione sul gestore risorse nel flusso di log dell'oggetto di gestione transazioni associato.
Il gestore delle risorse può anche impostare un flag di TRANSACTION_MANAGER_VOLATILE quando chiama ZwCreateTransactionManager. Se questo flag è impostato, KTM non crea un flusso di log per l'oggetto di gestione transazioni. Inoltre, eventuali gestori di risorse aggiuntivi connessi all'oggetto di gestione transazioni devono essere volatili e impostare il flag di RESOURCE_MANAGER_VOLATILE.
Aggiunta di un gestore delle risorse a un TPS esistente
Se è necessario aggiungere un gestore di risorse aggiuntivo a un tps esistente, sono disponibili due opzioni:
Il nuovo gestore di risorse chiama ZwCreateTransactionManager per creare un proprio oggetto di gestione transazioni.
Usa questa opzione se il gestore delle risorse non comunica con altri gestori di risorse nel TPS.
Il nuovo gestore di risorse chiama ZwOpenTransactionManager per connettersi a un oggetto di gestione transazioni esistente.
Usare questa scelta se il gestore delle risorse deve comunicare con altri gestori di risorse nel TPS. Il gestore delle risorse che chiama ZwCreateTransactionManager deve condividere il GUID dell'oggetto di gestione transazioni, il nome del flusso di log o il nome dell'oggetto in modo che altri gestori di risorse possano chiamare ZwOpenTransactionManager. Questi altri gestori di risorse possono chiamare ZwQueryInformationTransactionManager per ottenere informazioni aggiuntive sull'oggetto di gestione transazioni.
Dopo aver aggiunto il gestore delle risorse al TPS, i client che conoscono il gestore delle risorse possono chiamare l'interfaccia client del gestore delle risorse.