Creating Custom WorkflowCommitWorkBatchService Services
The workflow runtime uses a WorkflowCommitWorkBatchService service whenever it needs to commit the results of a workflow execution. You can provide a custom WorkflowCommitWorkBatchService service to control how the commit logic is executed, for example, by providing a transactional context. If no WorkflowCommitWorkBatchService is specified, the workflow runtime creates a DefaultWorkflowCommitWorkBatchService when the runtime is started.
To create a custom WorkflowCommitWorkBatchService service, you must derive from the WorkflowCommitWorkBatchService base class. This class defines one virtual method, which you can override:
protected void CommitWorkBatch(CommitWorkBatchCallback commitWorkBatchCallback)
This method is called by the workflow runtime when it has a batch of work to commit, for example, when persisting changes to a workflow instance. The implementation of this method should invoke the CommitWorkBatchCallback method within an appropriate transactional scope.
Ambient Transactions
The base implementation checks if an ambient transaction that was originated by the workflow instance exists. If it does not find an ambient transaction, it creates one and calls the CommitWorkBatch delegate. However, if an ambient transaction does exist, the base implementation creates a DependentTransaction specifying BlockCommitUntilComplete from the DependentCloneOption enumeration, and then sets the ambient transaction equal to the newly created DependentTransaction. It does this so that the ambient transaction that is generated by the workflow instance cannot be completed until the work batch commit work is completed. If an exception occurs, the CommitWorkBatch servcie rolls back the transaction and re-throws the exception. You can use the FaultHandlerActivity to catch this exception. This enables you to retry the transaction as needed.
The only type of ambient transaction that is supported by the WorkflowCommitWorkBatchService is a transaction that originates from the workflow instance. Ambient transactions that originate from the host application or from the application executing the workflow runtime are temporarily removed from the current thread to reduce their side effects. After the workflow is idle, the original ambient transaction that was contained by the host is placed back in the thread. Therefore, Windows Workflow Foundation does not support the ability to bring transactions from the outside into a workflow instance.
See Also
Reference
DefaultWorkflowCommitWorkBatchService
WorkflowCommitWorkBatchService
Concepts
Developing Windows Workflow Foundation Services
Windows Workflow CommitWorkBatch Services