Dela via

Beständiga Client-Side fel

I vissa fall kan Message Queuing- flytta ett meddelande till målkön. Om köåtkomstkontrollerna till exempel inte tillåter att meddelandet flyttas från klient till server flyttas det felaktiga meddelandet till kön för obeställbara meddelanden på klientsidan. När detta inträffar tillåter com+-tjänsten för köade komponenter att en undantagsklass associeras med en komponent. Om du vill associera undantagsklassen med komponenten använder du fliken Avancerat på komponentegenskaperna i administrationsverktyget för Komponenttjänster. Du kan också associera undantagsklassen programmatiskt med hjälp av katalogkomponentattributet ExceptionClass för COM+ Administrativa funktioner.

Undantagsklassen definieras som antingen ProgID eller CLSID för en komponent som implementerar IPlaybackControl. Tjänsten för köade komponenter har en köövervakare med obeställbara bokstäver som söker igenom kön för obeställbara Xact-meddelanden. Om det finns ett meddelande i kön instansierar kön med obeställbara meddelanden den undantagshanterare som är associerad med målkomponenten och anropar IPlaybackControl::FinalClientRetry, vilket indikerar att det har uppstått ett oåterkalleligt fel på klientsidan.

Förutom IPlaybackControlbör undantagshanteraren implementera samma uppsättning gränssnitt som den serverkomponent som den hanterar undantag för. När IPlaybackControl::FinalClientRetry anropas, spelar körningstiden för köade komponenter tillbaka det misslyckade meddelandet till undantagshanteraren. På så sätt kan undantagshanteraren implementera ett alternativt beteende för meddelanden som inte kan flyttas till servern, till exempel genom att generera en kompenserande transaktion.

Om undantagshanteraren slutför alla metodanrop som spelas upp tas meddelandet bort från kön för obeställbara Xact-meddelanden och avvisas. Om undantagshanteraren dock avbryter meddelandet genom att returnera en felstatus från ett av metodanropen, returneras meddelandet till kön för obeställbara Xact-meddelanden. Följande händelsesekvens visar hur undantag på klientsidan hanteras:

  1. Message Queuing kan inte leverera ett meddelande till servern och placerar meddelandet i kön med obeställbara meddelanden i Xact.
  2. Kölyssnaren (DLQL) hittar ett meddelande i kön med obeställbara meddelanden i Xact.
  3. DLQL hämtar målkomponenten CLSID från meddelandet och söker efter en undantagsklass.
  4. DLQL instansierar undantagsklassen.
  5. DLQL-frågorna för IPlaybackControl- för undantagsklassen.
  6. DLQL anropar metoden IPlaybackControl::FinalClientRetry i undantagsklassen.
  7. DLQL spelar upp alla egenskaps- och metodanrop från meddelandet till undantagsklassen.
  8. DLQL tar bort meddelandet om undantagshanteraren slutför transaktionen. Undantagshanteraren kan utfärda IObjectContext::SetAbortoch meddelandet finns kvar i kön med obeställbara meddelanden.

Om något av föregående steg misslyckas finns meddelandet kvar i kön för obeställbara Xact-meddelanden.

När den startas läser DLQL varje meddelande i transaktionskön Message Queuing och instansierar undantagsklassen för varje meddelande om köade komponenter. När en har passerat genom kön väntar den på nya meddelanden. Sedan bearbetas varje nytt kömeddelande med obeställbara meddelanden när det tas emot.

Om du behöver ingripa i den process som beskrivs här eller om du behöver flytta ett giftmeddelande från den sista vilande kön använder du verktyget meddelandeflyttare. Mer information om verktyget meddelandeflyttare finns i Hantera fel.

Client-Side fel

Server-Side fel

 

 

  • Last updated on