Dauerhafte Client-Side Fehler
In einigen Fällen kann Nachrichten queuing eine Nachricht in die Zielwarteschlange verschieben. Wenn die Warteschlangenzugriffssteuerelemente beispielsweise nicht zulassen, dass die Nachricht von Client zu Server verschoben werden kann, wird die beleidende Nachricht in die clientseitige Totbuchstabenwarteschlange verschoben. Wenn dies auftritt, ermöglicht der COM+-Komponentendienst eine Ausnahmeklasse, die einer Komponente zugeordnet wird. Um die Ausnahmeklasse mit der Komponente zuzuordnen, verwenden Sie die Registerkarte "Erweitert " auf der Seite "Komponenteneigenschaften" des Komponentendienste-Verwaltungstools. Sie können die Ausnahmeklasse auch programmgesteuert zuordnen, indem Sie das Attribut "ExceptionClass"-Katalogkomponente der COM+ Administrativen Funktionen verwenden.
Die Ausnahmeklasse wird entweder als ProgID oder CLSID einer Komponente definiert, die IPlaybackControl implementiert. Der Warteschlangenkomponentendienst verfügt über einen toten Briefwarteschleifenmonitor, der die Xact-Briefwarteschleife überprüft. Wenn eine Nachricht in der Warteschlange vorhanden ist, instanziiert die tote Buchstabenwarteschlange den Ausnahmehandler, der der Zielkomponente zugeordnet ist, und ruft IPlaybackControl::FinalClientRetry auf, der angibt, dass ein clientseitiger, nicht wiederherstellbarer Fehler vorhanden ist.
Zusätzlich zu IPlaybackControl sollte der Ausnahmehandler dieselbe Gruppe von Schnittstellen wie die Serverkomponente implementieren, für die Ausnahmen behandelt werden. Wenn IPlaybackControl::FinalClientRetry aufgerufen wird, wird die Ausführung der Warteschlangenkomponenten die fehlgeschlagene Nachricht an den Ausnahmehandler zurückgespielt. Dadurch kann der Ausnahmehandler ein alternatives Verhalten für Nachrichten implementieren, die nicht auf den Server verschoben werden können, z. B. durch Generieren einer Ausgleichstransaktion.
Wenn der Ausnahmehandler alle Methodenaufrufe abgeschlossen hat, die wiedergegeben werden, wird die Nachricht aus der Xact-Briefwarteschlange entfernt und wird geschlossen. Wenn der Ausnahmehandler jedoch die Nachricht abbricht, indem ein Fehlerstatus von einem der Methodenaufrufe zurückgegeben wird, wird die Nachricht in die Xact-Briefwarteschlange zurückgegeben. Die folgende Ereignissequenz zeigt, wie clientseitige Ausnahmen behandelt werden:
- Nachrichten queuing kann keine Nachricht an den Server senden und die Nachricht in die Xact-Briefwarteschlange einfügen.
- Der Listener für tote Buchstaben (DLQL) findet eine Nachricht in der Xact-Briefwarteschlange.
- Die DLQL ruft die Zielkomponente CLSID aus der Nachricht ab und sucht nach einer Ausnahmeklasse.
- Die DLQL instanziiert die Ausnahmeklasse.
- Die DLQL-Abfragen für IPlaybackControl für die Ausnahmeklasse.
- Die DLQL ruft die IPlaybackControl::FinalClientRetry-Methode in der Ausnahmeklasse auf.
- Die DLQL gibt alle Eigenschafts- und Methodenaufrufe aus der Nachricht in die Ausnahmeklasse zurück.
- Die DLQL löscht die Nachricht, wenn der Ausnahmehandler die Transaktion erfolgreich abgeschlossen hat. Der Ausnahmehandler kann IObjectContext::SetAbort darstellen, und die Nachricht bleibt in der Warteschlange für tote Buchstaben.
Wenn eine der vorhergehenden Schritte fehlschlägt, wird die Nachricht in der Xact-Totenbuchstabenwarteschlange links angezeigt.
Beim Start liest die DLQL jede Nachricht in der Transaktionswarteschlange "Message Queuing" und instanziiert die Ausnahmeklasse für jede Warteschlange. Nachdem eine Warteschlange durch die Warteschlange übergeben wurde, wartet sie auf neue Nachrichten. Anschließend wird jede neue Totbuchstabenwarteschlangennachricht verarbeitet, da sie eingetroffen wird.
Wenn Sie im hier beschriebenen Prozess eingreifen müssen oder wenn Sie eine Giftnachricht aus der endgültigen Restwarteschlange verschieben müssen, verwenden Sie das Nachrichten-Mover-Hilfsprogramm. Weitere Informationen zum Nachrichten-Mover-Hilfsprogramm finden Sie unter Behandeln von Fehlern.
Zugehörige Themen