0

I have some workflow 4 services with OperationContextScope activity wrapped around the Receive/SendReplyToReceive pairs to get access to the OperationContext.Current object. The OperationContextScope activity is from the WF Security Pack CTP at http://wf.codeplex.com/releases/view/48114. I use Windows Server AppFabric for hosting.

Now, I've just discovered that OperationContextScope establishes a no-persist zone. Since OperationContextScope is used by wrapping a sequence starting with a Receive and ending with a SendReplyToReceive, no persistance can take place at the time the workflow reaches the Receive.

This causes a problem since I have set up AppFabric to persist immediately when the workflow becomes idle, and it becomes idle when it reaches a Receive activity. The persist does not take place. I have also configured AppFabric to unload idle activities after 60 seconds. So after 60 seconds of idling at the Receive, my instance is wiped from memory, but, without getting persisted first.

As far as I understand, the instance will then resume from its last persistance point and continue until it reaches the same Receive as before. And again, it will fail to persist, unload after 60 seconds, resume from last persisted point, and so on.

To me, it seems like the OperationContextScope activity has a design flaw as it prevents automatic persistance and unloading of instances to happen as it should. Or am I using the activity the wrong way?

jonsb
  • 2,016
  • 3
  • 21
  • 24

1 Answers1

0

The problem is the OperationContextScope is providing you data from an ambient ongoing WCF call. This call itself does not magically go to sleep and resume like the workflow can. There's someone on the other side of that call waiting for a response and, usually, a network connection of some kind that can't be magically reestablished when the workflow finally wakes up.

So, maybe if you can describe more about the originating call we could prescribe some changes to the design that would make this possible. For example you could make the original call a one-way call and eventually call back to the caller via a separate endpoint.

Drew Marsh
  • 33,111
  • 3
  • 82
  • 100
  • What I'm trying to say is that a workflow instance becomes idle when it reaches a Receive, and it's useful to persist and unload the instance after idling at that Receive for a while, since in a long-running workflow it could take days or weeks before that call is actually made. What happens during a call is another matter, and I don't want to persist at that time. – jonsb Apr 17 '12 at 06:20