Comments on: System.Transactions and Workflows

By: Tomas Restrepo

Tomas Restrepo — Mon, 16 Jul 2007 11:24:45 +0000

Mark: That’s certainly a testament to the power and flexibility of WF. It sure looks like you’ve successfully customized it to work exactly how you want to, in a pretty cool way!
Not all projects, however, can undertake fairly big customizations of the workflow hosting infrastructure such as yours, and even then, circumstances may prevent them from using your specific approach.

By: Mark Johnson

Mark Johnson — Mon, 16 Jul 2007 09:59:11 +0000

Need to clarify that the time span from one Event handler to the next, must be less than the transaction timeout. Obviously this is a significant constraint if your workflow has many complex activities between EventHandlers. But it seems to me like workflows are mostly waiting for input from external actors and the activities themselves should execute in a reasonable timeframe.
Anothe Caveat: The default TransactionScopeActivity will stop working correctly. This could be overcome be creating a custom TransactionScopeActivity or by further modification to the custom SqlWorkflowPersistenceService.

By: Mark Johnson

Mark Johnson — Mon, 16 Jul 2007 09:39:12 +0000

On our current project, the requirement was that workflows be entirely transactional. These are long running statemachine workflows. The following are the steps required:
1) Use ManualWorkflowSchedulerService
2) By default WF does not flow in ambient transactions, so a custom TransactionService (a double dictionary keyed by thread and instanceID) must be used. Set the Transaction.Current in the service for the current thread before invoking an event on the workflow.
3) Exceptions do not flow out of the WF runtime, so a custom exception service is required (very similar to the transaction service) to re-throw exceptions after an event is raised on the workflow.
4) The default SqlWorkflowPersistenceService must be customized (Reflector works good) to set ‘Enlist=true’ (this is required for loading workflow instance so it is part of the same transaction to prevent deadlocks)
5) Create a base activity that all activities should derive from. This simply creates a TransactionScope (using the transaction stored in the TransactionService for the thread and instance) and calls the derived class’s ‘DoExecute’ method.
6) Instance.Unload must occur after firing an event and within the same TransactionScope
If any exception occurs during an Activity’s Execute method, the transaction is rolled back and the State Machine is returned to it’s original state. This setup will allow any number of events to be invoked on any number of Workflow Instances within the same transaction. A transaction is only valid on the thread it was created (at least the way we built it).
Even though the workflow is long running (many years), each activity must execute before the transaction times out (3 minutes in our case)