Działanie zablokowanego wyjątku wystąpienia
Właściwość InstanceLockedExceptionAction magazynu wystąpień przepływu pracy SQL umożliwia określenie akcji, jaką dostawca trwałości SQL powinien podjąć po odebraniu InstanceLockedExceptionelementu . Dostawca trwałości otrzymuje ten wyjątek, gdy próbuje zablokować wystąpienie usługi przepływu pracy, które jest obecnie zablokowane przez innego hosta usługi. Wartości tej właściwości to NoRetry, BasicRetryi AggressiveRetry. Wartość domyślna to NoRetry. Na poniższej liście opisano trzy opcje:
NoRetry. Host usługi nie próbuje zablokować wystąpienia usługi przepływu pracy i przekazuje InstanceLockedException obiekt wywołujący. Jeśli przepływ pracy pozostaje w pamięci przez okres przekraczający 60 sekund, użyj go NoRetry jako ponawiania próby. Wartość domyślna to NoRetry.
BasicRetry. Host usługi reattempts, aby zablokować wystąpienie usługi przepływu pracy z liniowym interwałem między próbami ponawiania i przekazuje InstanceLockedException obiekt wywołujący na końcu sekwencji. Jeśli przepływ pracy pozostaje w pamięci około 5–60 sekund, a komunikaty docierają do partii, gdzie jest bardziej prawdopodobne, aby komunikaty wysyłane do tego samego wystąpienia na tym samym hoście przetwarzały wszystkie komunikaty przed zwolnieniem przepływu pracy, użyj polecenia BasicRetry , aby osiągnąć najlepsze opóźnienie bez marnowania zasobów.
AggressiveRetry. Host usługi ponownie blokuje wystąpienie usługi przepływu pracy z interwałem wycofywania wykładniczego między próbami ponawiania próby i przekazuje wyjątek do obiektu wywołującego na końcu sekwencji. Jeśli przepływ pracy pozostaje w pamięci przez bardzo krótki czas (mniej niż 5 sekund), lub farma sieci Web jest duża, a prawdopodobieństwo dostarczenia innego komunikatu do tego samego hosta nie jest bardzo wysokie, użyj AggressiveRetry , aby osiągnąć najlepsze opóźnienie.
Funkcja akcji wyjątku zablokowanego wystąpienia obsługuje następujące scenariusze. We wszystkich scenariuszach, jeśli właściwość instanceLockedExceptionAction właściwości SqlWorkflowInstanceStore jest ustawiona na BasicRetry lub AggressiveRetry, host w sposób przezroczysty ponawia próbę, aby okresowo uzyskiwać blokadę na wystąpieniach.
Włączenie bezproblemowego zamknięcia i nakładającego się recyklingu domen aplikacji. Załóżmy, że element AppDomain z hostem usługi z uruchomionymi wystąpieniami usługi przepływu pracy jest odzyskiwany, a nowa domena appDomain jest wprowadzana w celu równoległego obsługi nowych żądań, podczas gdy stary element AppDomain jest bezpiecznie wyłączany. Zamknięcie czeka, aż wystąpienia usługi przepływu pracy będą bezczynne, a następnie utrwala i zwalnia wystąpienia. Wszelkie próby hostów w nowej domenie aplikacji w celu zablokowania wystąpienia spowodują wystąpienie .InstanceLockedException
Skalowanie w poziomie trwałych przepływów pracy w jednorodnej farmie serwerów. Załóżmy, że węzeł farmy serwerów, na którym jest uruchomione wystąpienie przepływu pracy ulega awarii, a host przepływu pracy nie może usunąć blokad na uruchomionym wystąpieniu. Gdy host usługi uruchomiony w innym węźle farmy otrzymuje komunikat dla tego wystąpienia przepływu pracy, próbuje uzyskać blokady w tych wystąpieniach, które otrzymają InstanceLockedException. Blokady wygasną po pewnym czasie, ponieważ host, który miał odnowić blokadę, już nie istnieje.
Skalowanie w poziomie trwałych przepływów pracy w jednorodnej farmie serwerów. Załóżmy, że chcesz skalować trwały przepływ pracy przy użyciu wielu hostów za równoważeniem obciążenia sieciowego (Load Balancer sieci), hosta przepływu pracy uruchomionego w jednym węźle farmy ładuje wystąpienie przepływu pracy i przetwarza komunikat, a następny komunikat do wystąpienia jest kierowany do hosta uruchomionego w innym węźle, ponieważ równoważenie obciążenia sieciowego nie ma algorytmu routingu do dostarczania komunikatów do hosta, który już uruchamia wystąpienie. Po otrzymaniu komunikatu drugi host próbuje załadować wystąpienie przepływu pracy i otrzyma InstanceLockedException element, ponieważ pierwszy host ma blokadę w wystąpieniu. Pierwszy host odblokuje wystąpienie po zakończeniu przetwarzania pierwszego komunikatu, a drugi host uzyskuje blokadę po następnym ponawia próbę, ładuje wystąpienie i przetwarza drugi komunikat.
