Is there automatic reloading and executing when recovering from a crash?
Hi
This may be a stupid question but I really need to know what to do in this case. I'm developing a state machine workflow, I have an EventDrivenActivity with a TransactionScopeAcitivty in which I have activities to save to my data model. If something goes horribly wrong after the persistence point on the close of the TransactionScopeActivity before the persistence on idle (I have this set). Can I expect that when the outside factors are resolved the runtime will take care of reloading this partially complete EventDrivenActivity automatically and finish exection from after the TransactionScopeActivty. Or... am I going to need to ?somehow? check for this situation and load the workflow instance to have it continue exection?
Any help would be greatly appreciated!
Duncan
Hi
Thanks for the reply. I have performed an experiment on how *automatic* the recovery is in the situation I described above. I simulated a problem where persistence happened once on completion of my TransactionScopeActivity but did not make it to the second persistence point on idle.
It seems looking at the trace that when the runtime is (re)created it will load and schedule the workflow instances that require finishing of execution. This seems like the only time I could see that the runtime will attempt to finish these instances automatically. If anybody knows of any other time, say polling for incomplete persisted instances?
The interesting thing that is now a problem I need an approach to solve is that although the runtime loads and schedules these instances when the runtime is created execution does not start! why... I assume it is because I'm using the ManualWorkflowSchedulerService and it has no donated thread and no call to RunWorkflow on the scheduler to begin execution (we are exposing our workflow as a web service). If we do donate a thread for execution, we did this by calling another global scoped EventDrivenActivity / WebServiceInput, execution will continue from after the TransactionScopeActivity in the first EventDrivenActivity then it will try to process the new event.
Cheers
Duncan
Have you watched this screencast:
http://wf.netfx3.com/files/folders/screencasts/default.aspx?ppage=3
The specific sreencast is "Building a scheduling service"
Not only are you using a Manual Workflow SchedulerService, you are using the TransactionScopeActivity. If you watch the screencast, the author discusses some of the issues of building manual services such as retreiving the Dates to determine restarts, that particular screencast ends with a brief discussion that using Transactions complicates building a manual service because the scope drops to the acivity level.
I guess I would wonder why you want to use a manual scheduler service rather than adjust the default scheduler service?
Anyway, I thought the screencast might help, so I posted it.
Trevor
Hi Trevor,
Thanks for the reply. I watched the screencast that you pointed out and also "Using a scheduling service" in addition to that one. The ManualWorkflowSchedulerService is the recommended scheduling service when building workflows in ASP.NET, as mentioned in this screencast. We are exposing our workflow as an ASP.NET web service so this is the scheduler for us, remember that ASP.NET already manages a pool of threads to run requests on, we don't need workflow to be doing this also, we normally want only one thread handling each web service request. In regard to "retrieving the dates to determine restarts" I assume you are talking about the scheduler handling delay activities as noted in the screencast (which is a bit old now) the ManualWorkflowShedulerService has been updated now to handle this delayed work without you having to donate a thread and call RunWorkflow on the scheduler I believe. I didn't actually hear anything about the TransactionScopeActivity or transactions in the screencast. On top of this I would be very surprised if I had to write my own scheduler service for the application I'm building, it is pretty standard and I would expect would be covered with the OOB ManualWorkflowSchedulerService.
So I would still like an answer to my above post with regard to the ManualWorkflowSchedulerService. Anybody?
Cheers
Duncan
Hey Duncan,
Wont your workflow resume from the partial save point when it receives an event for the next state? The Web service module will load and start your workflow when it needs to deliver an event to it. Doesnt that scenario work for you?
Hi
Sorry for not posting earlier. We tried this test and recieved a correlation problem, I think that events in the state machine worklfow are correlated by the state. I don't understand correlation completely as I have not had much reason to use that mechanism however I assume it is used in a state machine to differentiate between the same event defined on different states.
From my tests this means that we could only resume the execution with another event if that event is defined on the same state as the eventdriven that persisted part way through, or on a parent state.
So say if the normal sequence was submit -> approve -> deliver and the submit persists after it's transactionscope but does not make it to the approval state, approve will not be able to finish the work because that event cannot be delivered until we're executing the approval state.
Cheers
Duncan
 Duncan Stewart wrote: |
| Sorry for not posting earlier. We tried this test and recieved a correlation problem, I think that events in the state machine worklfow are correlated by the state. I don't understand correlation completely as I have not had much reason to use that mechanism however I assume it is used in a state machine to differentiate between the same event defined on different states.
|
|
The workflow runtime does correlates based on the instance id.It is able to differentiate between the same events in different state by only subscribing for events that are in the current state. What was the error you were getting?Are you sure the workflow has not terminated?Try adding the following to your web.config file just below the configSections:
<system.diagnostics>
<switches>
<add name="System.Workflow LogToTraceListeners" value="1"/>
<add name="System.Workflow.Runtime.Hosting" value="All"/>
<add name="System.Workflow.Runtime" value="All"/>
<add name="System.Workflow.Runtime.Tracking" value="All"/>
<add name="System.Workflow.Activities" value="All"/>
</switches>
<trace autoflush="true" indentsize="4">
<listeners>
<add name="myListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="WFTrace.log"/>
</listeners>
</trace>
</system.diagnostics>
| Duncan Stewart wrote: |
| From my tests this means that we could only resume the execution with another event if that event is defined on the same state as the eventdriven that persisted part way through, or on a parent state.
|
|
If you haven’t already take a look at the sample found here.
| Duncan Stewart wrote: |
| So say if the normal sequence was submit -> approve -> deliver and the submit persists after it's transactionscope but does not make it to the approval state, approve will not be able to finish the work because that event cannot be delivered until we're executing the approval state.
|
|
Do you have the WaitForIdle flag set to true on your ExternalDataEventArgs?This will cause the event to not be delivered until after the workflow completes the transition to the next state and becomes idle.
