Creating Custom Persistence Services
You can implement a persistence service to save the run-time state of a workflow instance to a durable store and to retrieve the state from that store. At certain commit points during the execution of a workflow, the Windows Workflow Foundation runtime engine notifies the persistence service to persist the workflow's state information. This can occur, for example, when the workflow becomes idle, when a TransactionScopeActivity activity finishes executing, or when the host application calls the Unload method.
The Windows Workflow Foundation runtime engine does not persist state information itself. This functionality is provided by custom persistence services that are added to the engine during run time. The runtime engine is responsible for starting the persistence operations, and the custom persistence services are responsible for saving and loading persisted state date.
Warning
If you create a workflow that uses the TransactionScopeActivity activity, CompensatableTransactionScopeActivity activity, CompensatableSequenceActivity activity, or custom activities that use the PersistOnCloseAttribute attribute or implement the ICompensatableActivity interface, you must specify a persistence service to use or an exception is thrown when you execute the workflow.
Creating a Custom Persistence Service
You create a custom persistence service by deriving from the WorkflowPersistenceService abstract base class. This base class contains five abstract methods that you must override when you create your persistence service. These methods are shown in the following table.
| Method | Description |
|---|---|
Loads the specified completed scope back into memory. |
|
Loads the specified state of the workflow instance back into memory. |
|
Saves the specified completed scope to a data store. |
|
Saves the workflow instance state to a data store. |
|
Unlocks the specified workflow instance state. |
|
Determines whether to persist the specified workflow instance to storage when it becomes idle for a period of time. |
For a sample that demonstrates the Windows Workflow Foundation engine unloading a workflow by saving the workflow instance state through a custom persistence service, see Custom Persistence Service.
Locking Workflow State Information
The Windows Workflow Foundation runtime engine can lock workflow state information to prevent the loading of a single workflow by separate persistence services that run in multiple processes. However, the actual locking mechanism is implemented by the custom persistence service itself. This means that support is optional when you create your persistence service. If you choose to support locking of workflow state, you should lock access to workflow state when the unlock parameter is set to false when SaveWorkflowInstanceState is called, and when LoadWorkflowInstanceState is called. The workflow state information should remain locked until either the unlock parameter is set to true with a subsequent call to SaveWorkflowInstanceState or the UnlockWorkflowInstanceState method is called. You should throw a WorkflowOwnershipException if a process tries to load the workflow instance state which is in the locked state.
Persisting Workflow State Information Using Transactions
If your custom persistence service uses a durable store, you should use workflow transaction batching to defer writing workflow state information until a workflow commit point is reached. To do this, implement the IPendingWork interface in your custom persistence service class and add a work item that represents the pending changes to your durable store to the WorkBatch property.
See Also
Reference
Concepts
Persistence Overview
Windows Workflow Persistence Services
Developing Windows Workflow Foundation Services