Condividi tramite

errori Server-Side

  • Articolo

Il listener e il giocatore interagiscono per gestire i messaggi non elaborabili. Se una transazione riprodotta ha esito negativo, accodamento messaggi sposta nuovamente il messaggio di input nella coda di input. Il lettore interrompe la transazione se riceve un HRESULT non riuscito dal componente server o se rileva un'eccezione. Se il problema persiste, il listener potrebbe continuamente eseguire il ciclo nel modello seguente:

  • Rimuove dalla coda il messaggio
  • Crea un'istanza dell'oggetto
  • Subisce un rollback
  • Riporta il messaggio nella parte superiore della coda

Il servizio componenti in coda gestisce questo errore usando una serie di code di tentativi specifiche dell'applicazione. Creato quando il componente è installato, sono presenti sette code per ogni applicazione, come indicato di seguito:

  1. Coda di input normale. Il nome di questa coda è il nome dell'applicazione COM+. Si tratta di una coda pubblica di accodamento messaggi.

  2. Prima coda di tentativi. I messaggi vengono spostati qui se la transazione ha esito negativo ripetutamente durante l'elaborazione dei messaggi dalla normale coda di input. I messaggi in questa coda vengono elaborati dopo un minuto. È possibile ritentare un messaggio tre volte in questa coda prima di essere spostato nella parte posteriore della seconda coda di tentativi. Questa coda è denominata ApplicationName_0. Questa coda è una coda di accodamento messaggi privata.

  3. Seconda coda di tentativi. I messaggi vengono spostati qui se la transazione ha esito negativo ripetutamente durante l'elaborazione dei messaggi dalla prima coda di tentativi. I messaggi in questa coda vengono elaborati dopo due minuti. È possibile ritentare un messaggio tre volte in questa coda prima di essere spostato nella parte posteriore della terza coda di tentativi. Questa coda è denominata ApplicationName_1. Questa coda è una coda di accodamento messaggi privata.

  4. Terza coda di tentativi. I messaggi vengono spostati qui se la transazione ha esito negativo ripetutamente durante l'elaborazione dei messaggi dalla seconda coda di ripetizione dei tentativi. I messaggi in questa coda vengono elaborati dopo quattro minuti. È possibile ritentare un messaggio tre volte in questa coda prima di essere spostato nella parte posteriore della quarta coda di tentativi. Questa coda è denominata ApplicationName_2. Questa coda è una coda di accodamento messaggi privata.

  5. Quarta coda di ripetizione dei tentativi. I messaggi vengono spostati qui se la transazione ha esito negativo ripetutamente durante l'elaborazione dei messaggi dalla terza coda di ripetizione dei tentativi. I messaggi in questa coda vengono elaborati dopo otto minuti. È possibile ritentare un messaggio tre volte in questa coda prima di essere spostato nella quinta coda di tentativi. Questa coda è denominata ApplicationName_3. Questa coda è una coda di accodamento messaggi privata.

  6. Quinta coda di tentativi. I messaggi vengono spostati qui se la transazione ha esito negativo ripetutamente durante l'elaborazione dei messaggi dalla quarta coda di ripetizione dei tentativi. I messaggi in questa coda vengono elaborati dopo sedici minuti. È possibile ritentare un messaggio tre volte in questa coda prima di essere spostato nella coda di riposo finale. Questa coda è denominata ApplicationName_4. Si tratta di una coda di accodamento messaggi privata.

  7. Coda di riposo finale specifica dell'applicazione. I messaggi vengono spostati qui se la transazione viene interrotta ripetutamente quando viene tentata la quinta coda di tentativi. Questa coda è denominata ApplicationName_DeadQueue. Si tratta di una coda di accodamento messaggi privata. La coda di riposo finale non viene eseguita da un listener di coda. I messaggi rimangono qui finché non vengono spostati manualmente (ad esempio dall'utilità di spostamento messaggi dei componenti in coda) o vengono eliminati da Esplora accodamento messaggi.

I messaggi che non sono riproducibili perché è chiaro che ogni tentativo di ripetizione avrà esito negativo può essere spostato direttamente nella coda di riposo finale specifica dell'applicazione senza essere avanzati attraverso tutti i livelli di ripetizione dei tentativi.

Il giocatore emette un evento COM+ per notificare alle parti interessate che i messaggi non possono essere riprodotti. Gli eventi COM+ vengono generati nelle situazioni seguenti:

  • Quando una transazione viene interrotta
  • Quando un messaggio viene spostato da una coda a un'altra
  • Quando un messaggio viene depositato nella coda di riposo finale

I messaggi possono essere modificati prima di passare da una coda a un'altra. Il meccanismo di sicurezza dei componenti in coda COM+ consente di spostare un messaggio per ripetere le code di tentativi e quindi reinserirlo nella coda di input iniziale dell'applicazione. Per altre informazioni sulla sicurezza dei componenti in coda, vedere Sicurezza dei componenti in coda.

Le code di ripetizione dei tentativi vengono create insieme alla coda principale dell'applicazione quando l'applicazione viene contrassegnata come in coda dallo strumento di amministrazione di Servizi componenti o tramite le funzioni COM+ Administrative SDK. Il servizio componenti in coda consente la flessibilità nel meccanismo di ripetizione dei tentativi consentendo l'eliminazione delle code di ripetizione dei tentativi. Ad esempio, se vengono eliminate tutte le code di ripetizione dei tentativi, verrà spostato un messaggio che interrompe in modo permanente direttamente dalla coda dell'applicazione alla coda di riposo finale specifica dell'applicazione. Rimuovendo una o più code di ripetizione dei tentativi, è possibile ridurre il numero e la lunghezza dei tentativi. Se le code vengono rimosse dalla sequenza di ripetizione dei tentativi, la tempistica delle code rimanenti corrisponde alla posizione nella sequenza di code di ripetizione dei tentativi. Ad esempio, se si rimuove la coda di ripetizione dei tentativi ApplicationName_1, ApplicationName_2 e ApplicationName_3, i messaggi in ApplicationName_4 verranno elaborati come se la coda fosse la seconda coda di tentativi.

Il meccanismo di ripetizione dei tentativi è progettato per completare un messaggio, se possibile. In alcuni casi, potrebbe non essere possibile che il messaggio abbia esito positivo. Ad esempio, un cliente potrebbe tentare di prelevare denaro da un conto che non dispone di fondi sufficienti. In questi casi, è possibile gestire l'errore in diversi modi, tra cui:

  • Generare una diagnostica e generare un avviso
  • Creare una transazione di compensazione
  • Ignorare il problema e ignorare il messaggio

Analogamente agli errori persistenti sul lato client, il servizio componenti in coda consente di associare una classe di eccezione a un componente. La classe di eccezione è associata al componente usando la scheda avanzate nella pagina delle proprietà del componente dello strumento di amministrazione di Servizi componenti o tramite le funzioni amministrative COM+. La classe di eccezione consente allo sviluppatore di avere il controllo dopo che un messaggio è stato ritentato e prima che tale messaggio venga spostato nella coda di riposo finale specifica dell'applicazione. Per altre informazioni sulla classe di eccezione, vedere errori di Client-Side persistenti.

Di seguito è riportata la sequenza di eventi per la gestione delle eccezioni lato server:

  1. Il messaggio viene spostato tra le code di ripetizione dei tentativi specifiche dell'applicazione disponibili.
  2. Il nuovo tentativo finale dell'ultima coda di tentativi ha esito negativo.
  3. Il runtime del servizio componenti in coda recupera il componente di destinazione dal messaggio e verifica la presenza di una classe di eccezione.
  4. L'istanza di runtime crea un'istanza della classe di eccezione.
  5. Le query di runtime IPlaybackControl nella classe di eccezione.
  6. Il runtime chiama IPlaybackControl::FinalServerRetry nella classe di eccezione.
  7. Il runtime riproduce tutte le chiamate di proprietà e metodo dal messaggio alla classe di eccezione.
  8. Se i passaggi da 4 a 6 non hanno esito positivo, il messaggio viene spostato nella coda di riposo finale specifica dell'applicazione.

Se è necessario intervenire nel processo descritto in precedenza 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.

Client-Side errori

errori di Client-Side persistenti