Normally the workflow is persisted when it becomes idle. How soon it gets persisted also depends upon factors such as the polling interval ( which you would have provided while creating the SQLPersistenceService
and attaching it to the runtime.) Also Everything that the workflow uses, esp. The ExternalDataEvent args and the events should be marked as Serializable
.
Regarding handling Exceptions, you should add FaultHandlersActivity to your workflow, and the exception that is caught, will be saved in the Fault property that gets exposed along with the FaultHandlersActivity.
Hope that's helpful.
There's a couple of issues going on here. First, when you are using SQL persistence, notifying the workflow of events and having the workflow publish events is persistent and asynchronous and the underlying plumbing of the workflow is transactional...but not in the way you might think.
If something horrible happens somewhere in the sequence of events that will eventually cause your workflow to transition to a new state, then the workflow will revert to the state it was in before attempting the activity - this keeps the workflow in a consistent state since being "between states" is a bad idea.
Using a transaction scope as you've done above is fine, but you have to remember that the only time transaction scopes actually work is when the classes within the using block are aware of the the transaction scope.
What you can do is have your call to "MyMethod" wrap things in a try/catch block. When something goes wrong, you can vote for a rollback... but this still doesn't "un-invoke" the method on your EDES.
If you can give some specifics about what you're trying to accomplish at a higher level, there may be some things intrinsic to the WF that might better suit you than trying to shoehorn a transaction scope into the mix.
Edit
I did some digging and found a couple of different places where we are told that there is no API to manipulate the scheduler work queue. Unfortunately for us what this means is that any sort of rollback behavior that we want we're going to have to implement by hand on our own.
If I knew more about why you were trying to rollback work queued through an EDES I might be able to suggest some potential architectures for accomplishing your task without re-inventing the wheel (transactions).
9 times out of 10 when I run into problems like this where it looks like WF just doesn't support what I'm trying to do, the problem is because I've either kept too much code outside the workflow or tried to put too much code into it and refactoring where my work is done often fixes my problem without requiring me to write new stuff.
Best Answer
State machines are really nice for event-driven code. You can't use loops and branches if your code is being invoked as a response to some event. You'll have to use a state machine instead, feed the events into it to change the state, and have the event handler react according to the machine's current state.