Programming WCF Services, 3rd Edition

Transaction Protocols and Managers

By and large, WCF developers need never concern themselves with transaction protocols and transaction managers. You should rely on WCF (and .NET) to select the correct protocol and transaction manager, and focus instead on implementing your logic. However, I have found that developers typically care a great deal about this issue, so I’ve chosen to include a discussion of transaction protocols and managers (mostly to demonstrate that there is no practical reason to actually deal with them in the first place).

The transaction management protocol WCF chooses depends on the execution scope of the participating parties in the transaction. The word protocol may be misleading here, because in the abstract the protocol being used is the two-phase commit protocol. The differences between the transaction management protocols have to do with the type of remote calls and communication protocol used, and the kind of boundaries it can cross. The options are:

The lightweight protocol

This protocol is used to manage transactions in a local context only, inside the same app domain. It cannot propagate the transaction across the app domain boundary (let alone the process or machine boundary), nor can it flow the transaction across any service boundary (that is, from a client to a service). The lightweight protocol is used only inside a service or between two parties in the same app domain, never between services. The lightweight protocol yields the best performance ...