Question

I’ve been working with some ExternalDataExchange – based communication in WF recently. My understanding is that when working with a long-running (in this case, a State Machine) workflows, communication is queued, durable, and transactional.

I’m using SQL Persistence and a EventArgs that is marked as “WaitForIdle = true”.

I would assume that when I do something like this:

using(TransactionScope scope = new TransactionScope())
{
     IMyEDEService service = wfRuntime.GetService<IMyEDEService>()
     service.MyMethod(wfInstanceGuid, "Here's some data");
     DoSomeDatabaseWork();
} //Dispose causes scope to rollback

I would expect that my event won’t fire on the workflow. It appears to actually be delivered, though, so this leads me to believe this is not transactional. You could see how the data committed to a database in DoSomeDatabaseWork() being rolled back, but the workflow moving foward could be bad.

Can anyone confirm this and if so, do you have a workaround to make the message a transactional one?

Really what I want is one of these two things:

1. The workflow shouldn’t react to the message I enqueued via external data exchange until the transaction that enqueued the message is committed (much like service broker does in SQL server).

–or–

2. If the workflow does start acting on the event I delivered, it should rollback as well. I don’t see how this could occur using the default scheduler, though. I’d like the workflow execution to remain asynchronous, so I don’t want to switch out the scheduler if I don’t have to.

Answer 1

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.