0

OperationContext.CurrentオブジェクトにアクセスするためにReceive/SendReplyToReceiveペアをラップしたOperationContextScopeアクティビティを備えたワークフロー4サービスがいくつかあります。OperationContextScopeアクティビティは、 http： //wf.codeplex.com/releases/view/48114にあるWF SecurityPackCTPからのものです。ホスティングにはWindowsServerAppFabricを使用しています。

さて、OperationContextScopeが非永続ゾーンを確立することを発見しました。OperationContextScopeは、Receiveで始まり、SendReplyToReceiveで終わるシーケンスをラップすることによって使用されるため、ワークフローがReceiveに到達したときに永続化を行うことはできません。

ワークフローがアイドル状態になるとすぐに持続し、受信アクティビティに達するとアイドル状態になるようにAppFabricを設定したため、これにより問題が発生します。永続化は行われません。また、60秒後にアイドル状態のアクティビティをアンロードするようにAppFabricを構成しました。したがって、Receiveで60秒間アイドリングした後、インスタンスはメモリから消去されますが、最初に永続化されることはありません。

私が理解している限り、インスタンスは最後の永続化ポイントから再開し、以前と同じ受信に到達するまで続行します。また、永続化に失敗し、60秒後にアンロードし、最後に永続化されたポイントから再開します。

私には、OperationContextScopeアクティビティには設計上の欠陥があるように見えます。これは、インスタンスの自動永続化とアンロードが適切に行われないようにするためです。または、アクティビティを間違った方法で使用していますか？

4

1 に答える 1

0

問題は、OperationContextScopeが進行中の周囲のWCF呼び出しからのデータを提供していることです。この呼び出し自体は、ワークフローのように魔法のようにスリープ状態になって再開することはありません。その呼び出しの反対側に応答を待っている人がいて、通常、ワークフローが最終的にウェイクアップしたときに魔法のように再確立できない種類のネットワーク接続があります。

したがって、発信元の呼び出しについて詳しく説明できれば、これを可能にする設計の変更を規定できます。たとえば、元の呼び出しを一方向の呼び出しにし、最終的には別のエンドポイントを介して呼び出し元にコールバックすることができます。

于 2012-04-16T15:40:34.790 に答える