Dela via

Åtgärd för instanslåst undantag

Med InstanceLockedExceptionAction egenskapen för SQL Workflow Instance Store kan du ange vilken åtgärd som SQL-beständighetsprovidern ska vidta när den tar emot en InstanceLockedException. Beständighetsprovidern får det här undantaget när den försöker låsa en instans av arbetsflödestjänsten som för närvarande är låst av en annan tjänstvärd. Värdena för den här egenskapen är NoRetry, BasicRetryoch AggressiveRetry. Standardvärdet är NoRetry. I följande lista beskrivs de tre alternativen:

  • NoRetry. Tjänstvärden försöker inte låsa instansen av arbetsflödestjänsten och skickar den InstanceLockedException till anroparen. Om arbetsflödet finns kvar i minnet i en period som överstiger 60 sekunder använder du NoRetry som återförsök. Standardvärdet är NoRetry.

  • BasicRetry. Tjänstvärden försöker igen att låsa arbetsflödestjänstinstansen med ett linjärt intervall mellan återförsök och skickar InstanceLockedException till anroparen i slutet av sekvensen. Om arbetsflödet stannar i minnet ungefär mellan 5 och 60 sekunder och meddelanden kommer i batchar där det är mer troligt att meddelanden skickas till samma instans på samma värd för att bearbeta alla meddelanden innan arbetsflödet tas bort, kan du använda BasicRetry för att uppnå bästa möjliga svarstid utan att slösa resurser.

  • AggressiveRetry. Tjänstvärden försöker igen att låsa arbetsflödestjänstinstansen med ett exponentiellt backoff-intervall mellan återförsök och skickar undantaget till anroparen i slutet av sekvensen. Om arbetsflödet finns kvar i minnet under en mycket kort tid (mindre än 5 sekunder) eller om en webbgrupp är stor och chansen att ett annat meddelande skickas till samma värd inte är särskilt hög kan du använda AggressiveRetry för att uppnå bästa möjliga svarstid.

Funktionen Åtgärd för instanslåst undantag stöder följande scenarier. I alla scenarier, om egenskapen instanceLockedExceptionAction för SqlWorkflowInstanceStore är inställd BasicRetry på eller AggressiveRetry, försöker värden transparent igen för att hämta låset på instanser med jämna mellanrum.

  1. Aktivera korrekt avstängning och överlappande återvinning av programdomäner. Anta att en AppDomain med en tjänstvärd som kör arbetsflödestjänstinstanser återanvänds och att en ny AppDomain tas upp för att hantera nya begäranden parallellt medan den gamla AppDomain tas bort på ett smidigt sätt. Avstängningen väntar tills instanserna av arbetsflödestjänsten är inaktiva och bevarar och tar sedan bort instanserna. Alla försök från värdar i den nya AppDomain att låsa en instans orsakar en InstanceLockedException.

  2. Horisontell skalning av hållbara arbetsflöden över en homogen servergrupp. Anta att en nod i en servergrupp där en arbetsflödesinstans kör kraschar och att arbetsflödesvärden inte kan ta bort lås på den instans som körs. När en tjänstvärd som körs på en annan nod i servergruppen tar emot ett meddelande för arbetsflödesinstansen försöker den hämta lås på dessa instanser som den tar emot InstanceLockedException. Låsen upphör att gälla efter en tid eftersom värden som skulle förnya låset inte längre finns.

    Horisontell skalning av hållbara arbetsflöden över en homogen servergrupp. Anta att du vill skala ett hållbart arbetsflöde horisontellt med flera värdar bakom en NLB (Network Load Balancer), arbetsflödesvärden som körs på en nod i servergruppen läser in en arbetsflödesinstans och bearbetar ett meddelande, och nästa meddelande till instansen dirigeras till värden som körs på en annan nod eftersom NLB inte har routningsalgoritm för att leverera meddelanden till värden som redan kör instansen. När den andra värden tar emot meddelandet försöker den läsa in arbetsflödesinstansen och tar emot InstanceLockedException eftersom den första värden har ett lås på instansen. Den första värden låser upp instansen när den är klar med bearbetningen av det första meddelandet och den andra värden hämtar låset när den försöker igen nästa gång, läser in instansen och bearbetar det andra meddelandet.