Search

Search:

Namespace:

Search Result
.
          • CompensatableTransactionScopeActivity
.
.
Summary
A version of the TransactionScopeActivity that use compensation logic instead of TrancactionScope.
.

To ensure consistency between the WorkflowInstance and the database being updated the TransactionScopeActivity is adorned with the PersistOnCloseAttribute. When the TransactionScopeActivity is used the WorkflowRuntime must be configured with a WorkflowPersistenceService. This could be the build in SqlWorkflowPersistenceService or another custom WorkflowPersistenceService.

.

The TargetActivityName must point to an activity of type ICompensatableActivity. By default there are two the CompensatableSequenceActivity and the CompensatableTransactionScopeActivity.

.

The Fault Handlers activity isn't an activity we can drag from the Toolbox into the workflow designer. Instead, the workflow designer will provide the activity for us when the condition is right. Many composite activities (like the WhileActivity, ListenActivity, SequenceActivity, TransactionScopeActivity, and others) can handle faults from their child activities using a fault handlers view

.

TransactionScopeActivity

.

Like the TransactionScope class of System.Transactions, the Transaction Scope activity will begin a new transaction and implicitly enlist the activities it contains into the transaction. The TransactionOptions property controls the timeout and the isolation level of the transaction (see figure 9).

.

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 Fault Handlers activity isn't an activity we can drag from the Toolbox into the workflow designer. Instead, the workflow designer will provide the activity for us when the condition is right. Many composite activities (like the WhileActivity, ListenActivity, SequenceActivity, TransactionScopeActivity, and others) can handle faults from their child activities using a fault handlers view

.

TransactionScopeActivity

.

Like the TransactionScope class of System.Transactions, the Transaction Scope activity will begin a new transaction and implicitly enlist the activities it contains into the transaction. The TransactionOptions property controls the timeout and the isolation level of the transaction (see figure 9).

.

Standard there are two Activities that implement this interface, the CompensatableTransactionScopeActivity and the CompensatableSequenceActivity.

.
Summary
.

One of the standard IsolationLevel values as used in the standard TransactionScope.

. .
  • CompensatableTransactionScopeActivity
.
Summary
.

The TransactionScope can be used in a local transaction and be upgraded to a more complicated distributed transaction by the TransactionManager.

.
Summary
.

During normal operations the transaction is committed at the end of the TransactionScopeActivity. If an exception is raised somewhere inside the TransactionScopeActivity, for example by a ThrowActivity, a rollback is performed.

.

To ensure consistency between the WorkflowInstance and the database being updated the TransactionScopeActivity is adorned with the PersistOnCloseAttribute. When the TransactionScopeActivity is used the WorkflowRuntime must be configured with a WorkflowPersistenceService. This could be the build in SqlWorkflowPersistenceService or another custom WorkflowPersistenceService.

.

Both a WorkBatch and TransactionScopeActivity can be used to do transactional work in a workflow. The difference is that the TransactionScopeActivity commits all work as soon as the TransactionScopeActivity is finished while a WorkBatch saves all items to commit and only commits them when the workflow runtime determines there is a CommitPoint. Batching also uses a TransactionScope so both are transactional.

.

So what is the difference. Suppose your workflow doest some stuff, is unloaded into the persistence store, continues executing, starts an TransactionScopeActivity, doest some work, terminates the TransactionScopeActivity and then before the workflow is finished or persisted again has the runtime crash on it.

.

Now the transaction has completed and is committed but the state of the workflow is still as it was last persisted, ie before the TransactionScopeActivity was executed. Suppose the runtime is restarted, it will detect and reload the workflow and continue from the unloaded point so do the TransactionScopeActivity again.

.

Now if you use a WorkBatch to commit the data things work a little different. The WorkBatch is committed in a TransactionScope but this will include the WorkflowPersistenceService itself. So if the workflow runtime crashes before the batch is committed no work is saved at all and everything can safely be repeated. If on the other hand the batch is saved and the workflow runtime crashes after that the workflow will be restarted from the second time it was saved and not repeat the work done.