Programming WCF Services

Instance Management and Transactions

Because the service instance goes through the trouble of retrieving its state and saving it on every method call, why wait till the end of the transaction to destroy the object? A per-call service would therefore be the most natural programming model for a transactional WCF service. In addition, the behavioral requirements for a state-aware transactional object and the requirements of a per-call object are the same—both retrieve and save their state at the method boundaries (compare Example 4-3 with Example 7-15). In spite of the fact that the per-call instancing mode is the most congenial for transactions, WCF does support a per-session and even a singleton service, albeit with a considerably more complex programming model.

Per-Call Transactional Service

A far as a per-call service call is concerned, transactional programming is almost incidental. Every call on the service gets a new instance, and that call may or may not be in the same transaction as the previous call (see Figure 7-8).

Figure 7-8. Per-call service and transactions

Regardless of transactions, in every call the service gets and saves its state from a resource manager, so the methods are always guaranteed to operate on consistent state from the previous transaction or on the temporary yet well-isolated state of the current transaction in progress. A per-call service must vote and ...