執行個體鎖定的例外狀況動作
本主題僅適用於 Windows Workflow Foundation 4。
SQL 工作流程執行個體存放區的執行個體鎖定的例外狀況動作屬性，可讓您指定當 SQL 持續性提供者收到 InstanceLockedException 時應採取的動作。當持續性提供者嘗試鎖定目前由其他服務主機鎖定的工作流程服務執行個體時，就會收到這個例外狀況。這個屬性的值可以是 No Retry、Basic Retry 及 Aggressive Retry。預設值為「No Retry」。下列清單描述這三種選項：
No Retry (預設值)： 持續性提供者不會重新嘗試鎖定執行個體，並且會將 InstanceLockedException 傳遞至呼叫端。
Basic Retry： 持續性提供者會嘗試依線性重試間隔重新嘗試鎖定執行個體，而且不是會成功鎖定執行個體，就是會在序列結尾將 InstanceLockedException 傳遞至呼叫端。
Aggressive Retry： 持續性提供者會重新嘗試依指數遞增延遲重新嘗試鎖定執行個體，而且不是會成功鎖定執行個體，就是會在序列結尾將 InstanceLockedException 傳遞至呼叫端。一開始的間隔會很短暫，以期盡快取得鎖定，隨著每次嘗試失敗，間隔會越來越大。
執行個體鎖定的例外狀況動作功能支援下列案例。在所有案例中，如果 SqlWorkflowInstanceStore 的 instanceLockedExceptionAction 屬性設定為 BasicRetry 或 AggressiveRetry，主機會公開地定期重試取得鎖定執行個體。
啟用正常關機與應用程式定義域重疊回收： 假設要回收 AppDomain (服務主機正在執行工作流程服務執行個體)，並使用新的 AppDomain 平行處理新的要求，而將舊的 AppDomain 正常關機。關機作業會等到工作流程服務執行個體閒置時才進行，然後才保存及卸載執行個體。只要主機在新的 AppDomain 中嘗試鎖定執行個體，就會造成 InstanceLockedException。
跨同質伺服器陣列水平縮放長期工作流程： 假設正在執行工作流程執行個體的伺服器陣列節點當機，且該工作流程主機無法移除其所執行之執行個體的鎖定。當在陣列的其他節點上執行的服務主機收到給該工作流程的訊息時，服務主機就會嘗試取得鎖定這些會收到 InstanceLockedException 的執行個體。鎖定會在一段時間後逾期，因為應更新鎖定的主機已不存在。
跨同質伺服器陣列水平縮放長期工作流程： 假設您要使用 NLB (網路負載平衡器) 之後的多部主機水平縮放長期工作流程，在其中一個陣列節點上執行的工作流程主機會載入工作流程執行個體並處理訊息，傳送至該執行個體的下一個訊息會路由至執行在其他節點上執行的主機，因為 NLB 沒有可將訊息傳遞至已執行該執行個體之主機的路由演算法。第二部主機收到訊息時，會嘗試載入工作流程執行個體並接收 InstanceLockedException，因為第一部主機已在該執行個體上鎖定。第一部主機會在完成處理第一個訊息時解除鎖定該執行個體，而第二部主機會在下次重試時取得鎖定、載入執行個體，並且處理第二個訊息。