Errori lato client persistente
In alcuni casi, Accodamento messaggi può spostare un messaggio nella coda di destinazione. Ad esempio, se i controlli di accesso alla coda non consentono lo spostamento del messaggio da client a server, il messaggio che causa l'errore viene spostato nella coda dei messaggi non recapitabili sul lato client. In questo caso, il servizio componenti in coda COM+ consente di associare una classe di eccezione a un componente. Per associare la classe di eccezione al componente, usare la scheda Avanzate nella pagina delle proprietà del componente dello strumento di amministrazione di Servizi componenti. È anche possibile associare la classe di eccezione a livello di codice usando l'attributo del componente del catalogo ExceptionClass delle funzioni COM+ Amministrazione istrative.
La classe di eccezione viene definita come ProgID o CLSID di un componente che implementa IPlaybackControl. Il servizio componenti in coda dispone di un monitoraggio della coda di messaggi non recapitabili che analizza la coda di messaggi non recapitabili Xact. Se è presente un messaggio nella coda, il monitoraggio della coda dei messaggi non recapitabili crea un'istanza del gestore eccezioni associato al componente di destinazione e chiama IPlaybackControl::FinalClientRetry, a indicare che si è verificato un errore sul lato client, irreversibile.
Oltre a IPlaybackControl, il gestore eccezioni deve implementare lo stesso set di interfacce del componente server per il quale gestisce le eccezioni. Quando viene chiamato IPlaybackControl::FinalClientRetry , il runtime dei componenti in coda riproduce il messaggio di errore al gestore eccezioni. Ciò consente al gestore eccezioni di implementare un comportamento alternativo per i messaggi che non possono essere spostati nel server, ad esempio generando una transazione di compensazione.
Se il gestore eccezioni completa tutte le chiamate al metodo riprodotte, il messaggio viene rimosso dalla coda dei messaggi non recapitabili Xact e viene ignorato. Se, tuttavia, il gestore eccezioni interrompe il messaggio restituendo uno stato di errore da una delle chiamate al metodo, il messaggio viene restituito alla coda dei messaggi non recapitabili Xact. La sequenza di eventi seguente mostra come vengono gestite le eccezioni sul lato client:
- Accodamento messaggi non riesce a recapitare un messaggio al server e inserisce il messaggio nella coda dei messaggi non recapitabili Xact.
- Il listener della coda dei messaggi non recapitabili (DLQL) trova un messaggio nella coda dei messaggi non recapitabili Xact.
- DLQL recupera il CLSID del componente di destinazione dal messaggio e verifica la presenza di una classe di eccezione.
- DLQL crea un'istanza della classe di eccezione.
- Query DLQL per IPlaybackControl per la classe di eccezione.
- DLQL chiama il metodo IPlaybackControl::FinalClientRetry nella classe di eccezione.
- DLQL riproduce tutte le chiamate di proprietà e metodo dal messaggio alla classe di eccezione.
- LA funzione DLQL elimina il messaggio se il gestore eccezioni completa correttamente la transazione. Il gestore eccezioni può emettere IObjectContext::SetAbort e il messaggio rimarrà nella coda dei messaggi non recapitabili.
Se uno dei passaggi precedenti ha esito negativo, il messaggio viene lasciato nella coda dei messaggi non recapitabili Xact.
All'avvio, dlQL legge ogni messaggio nella coda di messaggi non recapitabili transazionali e crea un'istanza della classe di eccezione per ogni messaggio di componenti in coda. Dopo un passaggio attraverso la coda, attende nuovi messaggi. Elabora quindi ogni nuovo messaggio della coda di messaggi non recapitabili man mano che arriva.
Se è necessario intervenire nel processo descritto qui o se è necessario spostare un messaggio non elaboratore dalla coda di riposo finale, usare l'utilità di spostamento dei messaggi. Per altre informazioni sull'utilità di spostamento dei messaggi, vedere Gestione degli errori.
Argomenti correlati