Instanslåst undantagsåtgärd

Med InstanceLockedExceptionAction egenskapen för SQL Workflow Instance Store kan du ange vilken åtgärd 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 arbetsflödestjänstinstansen och skickar den InstanceLockedException till anroparen. Om arbetsflödet finns kvar i minnet under en period som överstiger 60 sekunder använder NoRetry du som nytt försök. Standardvärdet är NoRetry.

• BasicRetry. Tjänstvärden försöker igen för 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 ligger kvar 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, använder BasicRetry du för att uppnå bästa svarstid utan att slösa resurser.

• AggressiveRetry. Tjänstvärden försöker igen för 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 levereras till samma värd inte är särskilt hög kan du använda AggressiveRetry för att uppnå bästa svarstid.

Funktionen Instanslåst undantagsåtgärd stöder följande scenarier. I alla scenarier, om egenskapen instanceLockedExceptionAction för SqlWorkflowInstanceStore har angetts till BasicRetry eller AggressiveRetry, försöker värden transparent hämta låset på instanser med jämna mellanrum.

1. Aktivera en 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 arbetsflödestjänstinstanserna är inaktiva och bevarar och tar sedan bort instanserna. Alla försök av 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örs 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 InstanceLockedExceptionförsöker den hämta lås på dessa instanser som den tar emot . Låsen upphör att gälla efter en tid eftersom den värd 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 varaktigt 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 routningsalgoritmen för att leverera meddelanden till värden som redan kör instansen. När meddelandet tas emot försöker den andra värden läsa in arbetsflödesinstansen InstanceLockedException och tar emot 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 det försöker igen nästa gång, läser in instansen och bearbetar det andra meddelandet.