WCF tutorial | WCF Transaction
A transaction is a collection or group of one or more units of operation executed as a whole. It provides way to logically group single piece of work and execute them as a single unit. In addition, WCF allows client applications to create transactions and to propagate transactions across service boundaries.
Let us discuss more on challenge we will phased and how to recover from it.
- Consider a system maintained in consistent state, when application fail to perform particular operation, you should recover from it and place the system in the consistent state.
- While doing singe operation, there will be multiple atomic sub operation will happen. These operations might success or fail. We are not considering about sub operation which are failed. We mainly consider about the success operation. Because we have to recover all these state to its previous consistence state.
- Productivity penalty has to be payee for all effort required for handcrafting the recovery logic
- Performance will be decreased because you need to execute huge amount of code.
Best way to maintain system consistence and handling error-recovery challenge is to use transactions.
Below figure gives idea about transaction.
- Committed transaction: Transaction that execute successfully and transfer the system from consistence state A to B.
- Aborted transaction: Transaction encounters an error and rollback to Consistence State A from intermediate state.
- In-doubt transaction: Transactions fail to either in commit or abort.
Transactional programming requires working with a resource that is capable of participating in a transaction, and being able to commit or roll back the changes made during the transaction. Such resources have been around in one form or another for decades. Traditionally, you had to inform a resource that you would like to perform transactional work against it. This act is called enlisting. Some resources support auto-enlisting.
Transaction can be said as pure and successful only if meets four characteristics.
- Atomic - When transaction completes, all the individual changes made to the resource while process must be made as to they were all one atomic, indivisible operation.
- Consistent - transaction must leave the system in consistent state.
- Isolated - Resources participating in the transaction should be locked and it should not be access by other third party.
- Durable - Durable transactions must survive failures.
- Always create the service with Interface->Implementation format, mention the contract in Interface.
- Define the service in Class library and refer the class library in Host project. Don’t use service class in host project.
- Change the instance mode to per call as default.
- Always catch exception using try/catch block and throw exception using FaultException < T >.
- Logging and Include exception should be enable while compiling the project in debug mode. While in production deployment disable the logging and Include exception details.