このトピックの内容は、Windows Workflow Foundation 4 に該当します。
SQL Workflow Instance Store のインスタンス ロック 例外アクション プロパティでは、SQL 永続化プロバイダーが InstanceLockedException を受け取ったときに実行するアクションを指定します。永続化プロバイダーがこの例外を受け取るのは、別のサービス ホストが現在ロックしているワークフロー サービス インスタンスをこの永続化プロバイダーがロックしようとしたときです。このプロパティに指定可能な値は、[再試行なし]、[基本的な再試行]、[積極的な再試行] です。既定値は [再試行なし] です。この 3 つのオプションを次の一覧で説明します。
再試行なし (既定値): 永続化プロバイダーは、インスタンスをロックする処理を再試行せず、InstanceLockedException を呼び出し元に渡します。
基本的な再試行: 永続化プロバイダーは、一定の比率で長くなる再試行インターバルを使用して、インスタンスをロックする処理を再試行し、インスタンスを正常にロックするか、シーケンスの最後に InstanceLockedException を呼び出し元に渡します。
積極的な再試行: 永続化プロバイダーは、急激に長くなる遅延を使用して、インスタンスをロックする処理を再試行し、インスタンスを正常にロックするか、シーケンスの最後に InstanceLockedException を呼び出し元に渡します。できるだけ速くロックを取得するために、インターバルは最初は短く、処理に失敗するたびに長くなります。
インスタンス ロック例外アクション機能は、次のシナリオをサポートしています。いずれのシナリオでも、SqlWorkflowInstanceStore の instanceLockedExceptionAction プロパティが BasicRetry または AggressiveRetry に設定されていれば、ホストはインスタンスのロックを取得するために、再試行を自動的に繰り返します。
正常なシャットダウンの有効化およびアプリケーション ドメインの重複したリサイクル: ワークフロー サービス インスタンスを実行するサービス ホストを持つ AppDomain がリサイクルされていて、新しい要求を処理するために新しい AppDomain が起動され、古い AppDomain が正常にシャットダウンされることが想定されています。このシャットダウンは、ワークフロー サービス インスタンスがアイドル状態になるまで待機した後、このインスタンスを永続化してアンロードします。新しい AppDomain でインスタンスをロックする処理をホストが再試行すると、InstanceLockedException が発生します。
同種サーバー ファームでの永続的ワークフローの水平的スケーリング: ワークフロー インスタンスが実行されているサーバー ファームのノードがクラッシュし、ワークフロー ホストが実行しているインスタンスのロックを解除できないことを想定しています。ファームの別のノードで実行されているサービス ホストは、そのワークフロー インスタンスのメッセージを受け取ると、InstanceLockedException を受け取ることになる、これらのインスタンスのロックを取得する処理を試行します。ロックを更新することになっていたホストは存在しないため、ロックはしばらくすると期限切れになります。
同種サーバー ファームでの永続的ワークフローの水平的スケーリング: NLB (ネットワーク負荷分散) の内側で複数のホストを使用して永続的なワークフローを水平的にスケーリングし、ファームのいずれかのノードで実行されているワークフロー ホストがワークフロー インスタンスを読み込み、メッセージを処理することを想定しています。また、このインスタンスへの次のメッセージは別のノードで実行されているホストにルーティングされます。これは、すでにインスタンスを実行しているホストにメッセージを届けるルーティング アルゴリズムが NLB にないためです。メッセージを受け取ると、最初のホストがワークフロー インスタンスのロックを保持しているため、2 つ目のホストがこのインスタンスをロードする処理を試行し、InstanceLockedException を受け取ります。最初のホストは、最初のメッセージの処理を通じてロック解除が行われるときにこのインスタンスのロックを解除し、2 つ目のホストは、次に再試行を行い、インスタンスをロードして、2 つ目のメッセージを処理するときにロックを取得します。