This documentation is archived and is not being maintained.

Batching State Information in Workflows

Your workflow periodically saves its state to persistent storage at various checkpoints called persistence points. If something goes wrong in your workflow, it might be necessary for the runtime engine to retrieve that persisted information to return to a stable state. If two or more components are communicating, it is often useful to coordinate persistence so that the states of the components are consistent. Work batches are used by services external to the workflow to persist state information. These services batch their work items and share the same transaction as that of the workflow. If the workflow is not committing a transaction, some work items can still be batched by the services during persistence points.

Windows Workflow Foundation provides IWorkBatch and IPendingWork to help services and workflow instances persist state information.

In all the calls to the services initiated from the workflow, the runtime engine provides an IWorkBatch in its thread call context. Your service can add a pending work item to this work batch so that the runtime engine can commit all related work items in a single transaction. To add a work item to the batch or to register with the batch, use following statement:

WorkflowEnvironment.WorkBatch.Add(IPendingWork work, object workItem);

In addition, you can pass in an IPendingWork to the constructor for ExternalDataEventArgs.

Sequence of Actions When an Implementation of IPendingWork Is Invoked

  1. During initialization, the workflow creates a work batch.

  2. The workflow attaches the work batch to the invocation of a method on a component. Services can access the work batch in any of their methods by using the WorkflowEnvironment class.

Sequence of Actions at a Commit Point

  1. The workflow creates a transaction.

  2. The workflow iterates over the work batch and collects all work items for a component, maintaining order, to create a work batch. The workflow invokes the Commit method on the component, passing in the transaction and the work batch.

  3. The component adds the work in the work batch to the transaction.

  4. Steps 2 and 3 are repeated for all components with work items in work batches.

  5. When the Commit notifications are successful, the workflow commits the corresponding transaction.

  6. On successful commit of a transaction, the workflow iterates over the work batch and collects all work items per component as in step 2. The workflow invokes the Complete method for each component, passing in the corresponding transaction and work batch.

Sequence of Actions on a Workflow Fault

  1. The workflow identifies all work items related to the faulting scope and constructs a work batch.

  2. The workflow invokes the Complete method of each unique IPendingWork with completed status set to false for all work in the work batch.

  3. The workflow abandons all work batch items that belong to a child context of a TransactionScopeActivity activity or a CompensatingTransactionScopeActivity activity.

  4. The runtime maintains reference to all remaining work batch items after recovery from the fault. That work may then be committed at a future persistence point.

Retrying Work Batch Transactions

The DefaultWorkflowCommitWorkBatchService, SharedConnectionWorkflowCommitWorkBatchService, SqlWorkflowPersistenceService, and SqlTrackingService all have the ability to retry work batch commits. This functionality, enabled through the EnableRetries property, allows these services to keep trying to commit a work batch in the case of network timeouts, machine reboots, SQL Server process resets, etc.

The number of retries is set at 20. The first three retries occur immediately after each other. After that, there is a delay between each subsequent retry. Applications can adjust the connection timeout in their connection string to partially adjust the time between retries.

This property can be set programmatically or through a configuration file. For more information on how to set it programmatically, see the EnableRetries property on each of the services. For more information on how to set it through a configuration file, see Workflow Configuration Files.

See Also