Creazione di un Resource Manager

I responsabili delle risorse gestiscono i dati di ogni transazione e registrano le operazioni della transazione. Se un sistema di elaborazione delle transazioni (TPS) ha più gestione risorse, ogni resource manager 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 ad altra risorsa gestita da Resource Manager.

In genere, un gestore risorse in modalità kernel deve eseguire le attività seguenti nell'ordine elencato:

  1. Creare un flusso di log.

    I responsabili delle risorse possono usare Common Log File System (CLFS) o altre funzionalità di registrazione per mantenere 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 dello stato interno che potrebbero essere necessarie per ripristinare le transazioni.

  2. Creare un oggetto gestione transazioni.

    Una chiamata a ZwCreateTransactionManager crea un oggetto gestione transazioni e connette il gestore risorse a un flusso di log CLFS aggiuntivo specificato da Resource Manager.

  3. Ripristinare lo stato di Gestione transazioni.

    Una chiamata a ZwRecoverTransactionManager legge il flusso di log dell'oggetto di Gestione transazioni (che KTM gestisce) e determina se il TPS è stato arrestato prima che tutte le transazioni siano state completate, ad esempio perché il sistema si è arrestato in modo anomalo. KTM ripristina lo stato interno in base alle informazioni nel flusso di log.

  4. Creare un oggetto resource manager.

    Una chiamata a ZwCreateResourceManager crea un oggetto resource manager e lo associa all'oggetto gestione transazioni creato in precedenza.

  5. Ripristinare lo stato di Resource Manager.

    Una chiamata a ZwRecoverResourceManager causa l'arresto di KTM TRANSACTION_NOTIFY_RECOVER notifiche di gestione risorse per le transazioni in corso l'ultima volta che il gestore risorse è stato arrestato. Per informazioni sul modo in cui gestione risorse deve rispondere a queste notifiche, vedere Gestione delle operazioni di ripristino.

  6. 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 transazioni a Resource Manager. Ad esempio, gestione risorse potrebbe fornire una routine CreateDataObject simile a quella descritta dall'argomento Understanding TPS Components .

  7. Inserire in ogni transazione.

    Una chiamata a ZwOpenTransaction apre un handle all'oggetto transazione e quindi una chiamata a ZwCreateEnlistment crea un elenco per la transazione. L'inserimento consente al gestore risorse di ricevere un set specificato di notifiche delle transazioni.

  8. Abilitare la ricezione delle notifiche delle transazioni.

    Gestione risorse può chiamare ZwGetNotificationResourceManager per ottenere notifiche in modo sincrono oppure può chiamare TmEnableCallbacks per registrare una routine di callback ResourceManagerNotification che KTM chiama ogni volta che è disponibile una notifica.

  9. Richieste di accesso alle risorse del servizio dai client, ma non apportare le modifiche permanenti.

    Dopo aver creato un oggetto transazione, un client chiama in genere l'interfaccia di Resource Manager per accedere alla risorsa di Resource Manager. Ad esempio, un resource manager per un database potrebbe ricevere richieste di lettura e scrittura nel database.

    Gestione risorse deve registrare i risultati delle operazioni di lettura e scrittura in un flusso di log CLFS o in altre funzionalità di registrazione fino a quando non riceve una notifica che le operazioni della transazione verranno commit, rollback o ripristinate.

  10. Eseguire il commit o il rollback delle operazioni client.

    Alla fine, gestione risorse riceve una notifica per iniziare a eseguire il commit o il rollback delle operazioni eseguite dal client. In risposta, gestione risorse deve rendere permanenti le operazioni client o eliminarle. Per altre informazioni su come gestire le notifiche di commit e rollback, vedere Gestione delle operazioni transazioni.

    Occasionalmente, un resource manager potrebbe dover tentare di forzare KTM a fornire rapidamente una notifica di commit o rollback, forse perché resource manager ha determinato che un dispositivo è stato rimosso a sorpresa. In tal caso, gestione risorse può chiamare TmRequestOutcomeEnlistment.

  11. Chiudere l'handle dell'oggetto enlistment.

    Dopo aver completato l'elaborazione della transazione, è necessario chiamare ZwClose per chiudere l'handle dell'oggetto di inserimento

  12. Chiudere l'handle dell'oggetto resource manager e l'handle degli oggetti di Gestione transazioni.

    Prima di scaricare resource manager, deve chiamare ZwClose per chiudere l'handle dell'oggetto resource manager e l'handle dell'oggetto gestione transazioni.

I passaggi da 1 a 5 devono essere eseguiti nel codice di inizializzazione di Resource Manager. Ad esempio, se gestione risorse è 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 di Resource Manager, ad esempio una routine di scaricamento in modalità kernel.

Creazione di un Read-Only inserimento

Un inserimento di sola lettura è un elenco che non riceve alcuna notifica da KTM. Un gestore risorse può effettuare qualsiasi inserimento di sola lettura chiamando ZwReadOnlyEnlistment. Questa chiamata causa l'arresto delle notifiche da parte di KTM al resource manager.

Dopo che il gestore risorse ha chiamato ZwCreateEnlistment, può chiamare ZwReadOnlyEnlistment in qualsiasi momento fino al punto in cui chiamerebbe normalmente ZwPrepareComplete.

Esistono due motivi per cui è possibile che il gestore risorse chiami ZwReadOnlyEnlistment.

  • Gestione risorse ha partecipato a una transazione e, a un certo punto, prima di ricevere una notifica di TRANSACTION_NOTIFY_COMMIT, gestione risorse determina che non deve più partecipare all'operazione di commit della transazione.

    Ad esempio, quando gestione risorse riceve una notifica di TRANSACTION_NOTIFY_PREPARE, potrebbe determinare che nessuna delle operazioni della transazione ha modificato il database di Resource Manager. Il gestore risorse può chiamare ZwReadOnlyEnlistment anziché ZwPrepareComplete per rimuoverlo dalla transazione.

  • Resource Manager non partecipa mai all'operazione di commit della transazione.

    Ad esempio, gestione risorse potrebbe monitorare i dati inviati dal client, senza modificare alcun database archiviato. In questo caso, il gestore risorse potrebbe chiamare ZwReadOnlyEnlistment immediatamente dopo aver chiamato ZwCreateEnlistment. Inoltre, è possibile scegliere di rendere volatile tale resource manager, come descritto nella sezione successiva di questo argomento.

Dopo che un resource manager ha chiamato ZwReadOnlyEnlistment, può chiamare ZwClose per chiudere l'handle di inserimento.

Creazione di un Volatile-Resource Manager

Un gestore risorse volatile è un resource manager che non mantiene dati durevoli. Ad esempio, è possibile creare un gestore risorse volatile per monitorare i dati inviati dal client, se gestione risorse non modifica un database memorizzato in modo permanente. Le gestioni 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 informazioni sul gestore risorse nel flusso di log dell'oggetto gestione transazioni associato.

Il gestore 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 gestione transazioni. Inoltre, tutti gli altri gestori di risorse connessi all'oggetto gestione transazioni devono essere volatili e impostare il flag di RESOURCE_MANAGER_VOLATILE.

Aggiunta di un Resource Manager a un TPS esistente

Se è necessario aggiungere un gestore risorse aggiuntivo a un TPS esistente, sono disponibili due opzioni:

  • Il nuovo gestore risorse chiama ZwCreateTransactionManager per creare un proprio oggetto di gestione transazioni.

    Usare questa scelta se gestione risorse non comunica con altri gestori di risorse nel TPS.

  • Il nuovo gestore risorse chiama ZwOpenTransactionManager per connettersi a un oggetto gestione transazioni esistente.

    Usare questa scelta se gestione risorse deve comunicare con altri gestori di risorse nel TPS. Gestione risorse che chiama ZwCreateTransactionManager deve condividere il GUID dell'oggetto Gestione transazioni, il nome del flusso di log o il nome dell'oggetto in modo che altri responsabili delle risorse possano chiamare ZwOpenTransactionManager. Questi altri gestori di risorse possono chiamare ZwQueryInformationTransactionManager per ottenere informazioni aggiuntive sull'oggetto gestione transazioni.

Dopo aver aggiunto resource manager al TPS, i client che sono consapevoli della gestione risorse possono chiamare l'interfaccia client di Resource Manager.