'Shared Connection Workflow Commit Work Batch Service' and ASP.Net

After trying to make WWF tracking do what’s it’s supposed to do (out of the box nota bene) and failed a thousand times, I want to write a note here for the poor chap who will waste time just like me.

According to the documentation the SharedConnectionWorkflowCommitWorkBatchService was created to have persistence and tracking in one and the same data store:

The SharedConnectionWorkflowCommitWorkBatchService service is used for database transactions that use a shared connection between different objects. To use the SharedConnectionWorkflowCommitWorkBatchService instead of the DefaultWorkflowCommitWorkBatchService in your WorkflowRuntime instance, use the AddService method.

It does indeed but problems arise if you have an ASP.Net client and even more if your workflow is transactional. In my case the workflow was committing data to SQLServer and the transaction was using MSDTC to coordinate the database and the workflow. First, I would not get any tracking data without any reason and, second, the workflow would simply time out when I would switch the SharedConnectionWorkflowCommitWorkBatchService on. Switching the SharedConnectionWorkflowCommitWorkBatchService off would resolve the latter but the tracking data would still be lost somehow. Even unloading the workflow instance explicitly would not solve the time out problem.

Somewhere along my search for an answer I had to go deep into the threading mechanisms of ASP.Net in conjunction with WWF. I reckon the problem is indeed somewhere along this line; there are threads in IIS, using the ManualWorkflowSchedulerService a thread is handed over to the workflow and eventually the transaction mechanisms (over MSDTC) is communicating with the SQLServer thread(s). I tried to see if the issue was related to IIS7 or Vista, whether SQL Express was the cause or the VS2008 debugging environment…but no relief.

So, the conclusion is: don’t use the SharedConnectionWorkflowCommitWorkBatchService when your client is ASP.Net.

Instead: use separate databases for tracking and persistence.

In my case it solved all my problems; the workflow is transactional, persistent and data is tracked (in a separate database however). I think the compromise is fair and in a way it helps to keep applications and tracking separate. I think the biggest point for me was the lack of documentation when it comes to using workflows in a web environment. The best article I could find on this topic was Scott Allen’s well written sample.

I’m still a big fan of WWF though