次の方法で共有

インスタンス ロック例外アクション

  • [アーティクル]

SQL Workflow Instance Store の InstanceLockedExceptionAction プロパティでは、SQL 永続化プロバイダーが InstanceLockedException を受け取ったときに実行するアクションを指定します。 永続化プロバイダーがこの例外を受け取るのは、別のサービス ホストが現在ロックしているワークフロー サービス インスタンスをこの永続化プロバイダーがロックしようとしたときです。 このプロパティの値は NoRetry、BasicRetry、および AggressiveRetry です。 既定値は NoRetry です。 この 3 つのオプションを次の一覧で説明します。

  • NoRetry. サービス ホストは、ワークフロー サービス インスタンスをロックしようとせず、InstanceLockedException を呼び出し元に渡します。 ワーク フローが 60 秒間を超えてメモリに留まる場合は、再試行として NoRetry を使用します。 既定値は NoRetry です。

  • BasicRetry. サービス ホストは一定の再試行間隔でワークフロー サービス インスタンスのロックを再試行し、シーケンスの最後に InstanceLockedException を呼び出し元に渡します。 ワークフローがおよそ 5 ～ 60 秒間メモリに留まり、ワークフローをアンロードする前にすべてのメッセージを処理するため、同じホスト上の同じインスタンスに送信されるメッセージのようにメッセージがバッチで届く場合、リソースを無駄にしない最適な待ち時間を実現するため BasicRetry を使用します。

  • AggressiveRetry. サービス ホストは指数バックオフ間隔でワークフロー サービス インスタンスのロックを再試行し、シーケンスの最後に例外を呼び出し元に渡します。 ワーク フローがとても短い間 (5 秒以内) 目盛りに留まる場合、または Web ファームが大きく別のメッセージが同じホストに渡される可能性が高くない場合、最適な待ち時間を実現するため AggressiveRetry を使用します。

インスタンス ロック例外アクション機能は、次のシナリオをサポートしています。 いずれのシナリオでも、SqlWorkflowInstanceStore の instanceLockedExceptionAction プロパティが BasicRetry または AggressiveRetry に設定されていれば、ホストはインスタンスのロックを取得するために、再試行を自動的に繰り返します。

  1. 正常なシャットダウンの有効化およびアプリケーション ドメインの重複したリサイクル。 ワークフロー サービス インスタンスを実行するサービス ホストを持つ AppDomain がリサイクルされていて、新しい要求を処理するために新しい AppDomain が起動され、古い AppDomain が正常にシャットダウンされることを想定しています。 このシャットダウンは、ワークフロー サービス インスタンスがアイドル状態になるまで待機した後、このインスタンスを永続化してアンロードします。 新しい AppDomain でインスタンスをロックする処理をホストが再試行すると、InstanceLockedException が発生します。

  2. 同種サーバー ファームでの永続的ワークフローの水平的スケーリング: ワークフロー インスタンスが実行されているサーバー ファームのノードがクラッシュし、ワークフロー ホストが実行しているインスタンスのロックを解除できないことを想定しています。 ファームの別のノードで実行されているサービス ホストは、そのワークフロー インスタンスのメッセージを受け取ると、InstanceLockedException を受け取ることになる、これらのインスタンスのロックを取得する処理を試行します。 ロックを更新することになっていたホストは存在しないため、ロックはしばらくすると期限切れになります。

    同種サーバー ファームでの永続的ワークフローの水平的スケーリング: NLB (ネットワーク負荷分散) の内側で複数のホストを使用して永続的なワークフローを水平的にスケーリングし、ファームのいずれかのノードで実行されているワークフロー ホストがワークフロー インスタンスを読み込み、メッセージを処理することを想定しています。また、このインスタンスへの次のメッセージは別のノードで実行されているホストにルーティングされます。これは、すでにインスタンスを実行しているホストにメッセージを届けるルーティング アルゴリズムが NLB にないためです。 メッセージを受け取ると、最初のホストがワークフロー インスタンスのロックを保持しているため、2 つ目のホストがこのインスタンスをロードする処理を試行し、InstanceLockedException を受け取ります。 最初のホストは、最初のメッセージの処理を完了してロック解除が行われるときにこのインスタンスのロックを解除し、2 つ目のホストは、次に再試行を行い、インスタンスをロードして、2 つ目のメッセージを処理するときにロックを取得します。