The purpose of the DefaultWorkflowCommitWorkBatchService service is to enable custom logic for the commitment of work batches (also known as persistence points). When a work batch is committed, the workflow runtime calls into the DefaultWorkflowCommitWorkBatchService service and gives it a delegate to call to do the actual committing of the work batch. The runtime still has to do the commit; but it allows the service to insert itself into the process for customization around the commit process.

The only true requirement of the DefaultWorkflowCommitWorkBatchService service is to create a transaction if one does not already exist when its CommitWorkBatch method is called. If a transaction does not exist (which occurs when the Current property returns null), the DefaultWorkflowCommitWorkBatchService must create a transaction and set the ambient transaction before calling the CommitWorkBatchCallback delegate. This is done by wrapping the delegate call with a TransactionScope.

The primary reason for this service type is to enable custom error-handling logic. If the DefaultWorkflowCommitWorkBatchService service owns the transaction, because it created one when Current returns null (Nothing in Visual Basic), it can call the delegate more than once, creating a new transaction for each call. The most common example of this is to handle intermittent network problems or SQL cluster failovers. If the call to the CommitWorkBatchCallback throws an exception, WorkflowCommitWorkBatchService can catch this exception, start a new transaction, and call the delegate again. This gives a level of resilience to workflow instance execution that otherwise would cause workflows to terminate.

Note:

A WorkflowCommitWorkBatchService service can only retry the commit if it created the current ambient transaction. If an ambient transaction is already present when the runtime calls the CommitWorkBatch method, it means that some other object owns the transaction and might already have done work on it. Because the DefaultWorkflowCommitWorkBatchService service cannot reproduce the external work, it is not valid for it to retry the commit. An example of this would be a TransactionScopeActivity transaction or a transaction that was created by host code before it calls the Unload method.

See Also