Akce uzamčené výjimky instance

Vlastnost InstanceLockedExceptionAction úložiště instancí pracovního postupu SQL umožňuje určit, jakou akci má poskytovatel trvalosti SQL provést, když obdrží InstanceLockedException. Zprostředkovatel trvalosti obdrží tuto výjimku, když se pokusí uzamknout instanci služby pracovního postupu, která je aktuálně uzamčena jiným hostitelem služby. Hodnoty pro tuto vlastnost jsou NoRetry, BasicRetrya AggressiveRetry. Výchozí hodnota je NoRetry. Následující seznam popisuje tři možnosti:

• NoRetry. Hostitel služby se nepokouší uzamknout instanci služby pracovního postupu a předá InstanceLockedException volajícímu. Pokud váš pracovní postup zůstane v paměti po dobu delší než 60 sekund, použijte NoRetry ho jako opakování. Výchozí hodnota je NoRetry.

• BasicRetry. Hostitel služby znovu provede uzamčení instance služby pracovního postupu s lineárním intervalem mezi pokusy o opakování a předá InstanceLockedException volajícímu na konci sekvence. Pokud pracovní postup zůstává v paměti přibližně 5 až 60 sekund a zprávy přicházejí v dávkách, kde je pravděpodobnější, že zprávy odesílané do stejné instance na stejném hostiteli zpracovávají všechny zprávy před uvolněním pracovního postupu, použijte BasicRetry k dosažení nejlepší latence bez plýtvání prostředky.

• AggressiveRetry. Hostitel služby znovu provede uzamčení instance služby pracovního postupu s exponenciálním intervalem zpětného ukončení mezi pokusy o opakování a předá výjimku volajícímu na konci sekvence. Pokud váš pracovní postup zůstane v paměti po velmi krátkou dobu (méně než 5 sekund), nebo je webová farma velká a pravděpodobnost doručení další zprávy do stejného hostitele není příliš vysoká, použijte AggressiveRetry k dosažení nejlepší latence.

Funkce akce uzamčené výjimky instance podporuje následující scénáře. Pokud je ve všech scénářích nastavena BasicRetry vlastnost instanceLockedExceptionAction sqlWorkflowInstanceStore nebo AggressiveRetry, hostitel transparentně opakuje, aby získal zámek u instancí pravidelně.

1. Povolení řádného vypnutí a překrývající se recyklace domén aplikací Předpokládejme, že se recykluje appDomain s hostitelem služby, na kterém běží instance služby pracovních postupů, a nová doména AppDomain se vytvoří tak, aby zpracovávala nové požadavky paralelně, zatímco stará doména AppDomain se elegantně zmenší. Vypnutí počká, dokud instance služby pracovního postupu nebudou nečinné, a pak instance zachovají a odloží. Všechny pokusy hostitelů v nové AppDomain uzamknout instanci způsobí .InstanceLockedException

2. Horizontální škálování trvalých pracovních postupů napříč homogenní farmou serverů Předpokládejme, že uzel serverové farmy, na které je spuštěná instance pracovního postupu, dojde k chybě a hostitel pracovního postupu nemůže odebrat zámky v instanci, na které běží. Když hostitel služby spuštěný na jiném uzlu farmy obdrží zprávu pro tuto instanci pracovního postupu, pokusí se získat zámky na těchto instancích, obdrží InstanceLockedExceptionzprávu . Zámky vyprší po nějaké době, protože hostitel, který by měl zámek obnovit, již neexistuje.

   Horizontální škálování trvalých pracovních postupů napříč homogenní farmou serverů Předpokládejme, že chcete horizontálně škálovat trvalý pracovní postup pomocí více hostitelů za vyrovnáváním zatížení sítě (Network Load Balancer), hostitel pracovního postupu spuštěný na jednom uzlu farmy načte instanci pracovního postupu a zpracovává zprávu a další zpráva do instance je směrována na hostitele, který běží na jiném uzlu, protože služba NLB nemá algoritmus směrování pro doručování zpráv hostiteli, který už instanci spouští. Po přijetí zprávy se druhý hostitel pokusí načíst instanci pracovního postupu a obdrží InstanceLockedException , protože první hostitel má na instanci zámek. První hostitel odemkne instanci po dokončení zpracování první zprávy a druhý hostitel získá zámek při příštím opakování instance, načte instanci a zpracuje druhou zprávu.