Transactional Delivery of Data
The previous section explored how the progress of a WF program instance, which unfolds episodically, is recorded using transactionsand, significantly, also how transaction-aware services utilized by activities can participate in these transactions. Essentially, what we learned boils down to a model for how WF program instances can send data to external systems in a transactional manner.
Now we can
public void EnqueueItem(IComparable queueName, object item, IPendingWork service, object workItem);
parameter is the
The item parameter is the data that is being enqueued.
When we used the EnqueueItem method in the code snippets of earlier chapters, we only used the first two parameters and passed a value of null for the other two. Now, though, you can guess that it is precisely these latter two parameters that give us the ability to enqueue data in a transactional manner.
When an item is enqueued into a WF program instance queue, it is available for processing by the WF program instance. However, just as we discussed earlier, the WF program instancethough it can
If we pass
as the value of the latter two parameters of
, and a failure occurs before the next WF program instance persistence point, the enqueued data is lost. Instead, if we provide a transaction-aware service and a work item when we enqueue the data, our service will get called when the next persistence point in the WF program instance is reached. A transaction will then be available so that our service can
Where are We?
In this chapter, we learned how WF program instances are executed in a durable and transactional manner. Because the execution progress of a WF program instance is recorded
The transactionScopeActivity activity allows us to explicitly model transactional boundaries in a WF program. The transaction used by a transaction-ScopeActivity is the same transaction that is used to persist the WF program instance at the end of the execution of the transactionScopeActivity .
We saw how to write an activity that lets us