Sunday, 18 January 2015

Transaction in WCF



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.

Recovery Challenge:
Let us discuss more on challenge we will phased and how to recover from it.
1)     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.
2)     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.
3)     Productivity penalty has to be payee for all effort required for handcrafting the recovery logic.
4)     Performance will be decreased because you need to execute huge amount of code.
Solution: 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.

Transaction Resources:
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 Properties:
Transaction can be said as pure and successful only if meets four characteristics.
1)    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.
2)    Consistent - transaction must leave the system in consistent state.
3)    Isolated - Resources participating in the transaction should be locked and it should not be access by other third party.
4)    Durable - Durable transactions must survive failures.

Two-phase committed protocol:

Consider the scenario where I am having single client which use single service for communication and interacting with single database. In which service starts and manage the transaction, now it will be easy for the service to manage the transaction.
Consider for example client calling multiple service or service itself calling another service, this type of system are called as Distributed Service-oriented application. Now the questions arise that which service will begin the transaction? Which service will take responsibility of committing the transaction? How would one service know what the rest of the service feels about the transaction? Service could also be deployed in different machine and site. Any network failure or machine crash also increases the complexity for managing the transaction.
In order to overcome these situations, WCF come up with distributed transaction using two way committed protocol and dedicated transaction manager.
Transaction Manager is the third party for the service that will manage the transaction using two phase committed protocol.
Let us see how Transaction manager will manage the transaction using two-phase committed protocols.


Transaction Propagation:

In WCF, transaction can be propagated across service boundary. This enables service to participate in a client transaction and it includes multiple services in same transaction, Client itself will act as service or client.
We can specify whether or not client transaction is propagated to service by changing Binding and operational contract configuration
<bindings>
      <netTcpBinding>
        <binding transactionFlow="true"></binding>
      </netTcpBinding>
</bindings>
Even after enabling transaction flow does not mean that the service wants to use the client’s transaction in every operation. We need to specify the “TransactionFlowAttribute” in operational contract to enable transaction flow.
[ServiceContract]
public interface IService
{
 
    [OperationContract]
    [TransactionFlow(TransactionFlowOption.Allowed)]
    int Add(int a, int b);
 
    [OperationContract]
    int Subtract(int a, int b);
}
Note: TransactionFlow can be enabled only at the operation level not at the service level.
TransactionFlowOption
Binding configuration

NotAllowed
transactionFlow="true" 
or
transactionFlow="false"
Client cannot propagate its transaction to service even client has transaction.
Allowed
transactionFlow="true"
Service will allow to flow client transaction.
It is not necessary that service to use client transaction.
Allowed
transactionFlow="false"
If service disallows at binding level, client also should disable at binding level else error will be occurred.
Mandatory
transactionFlow="true"
Both Service and client must use transaction aware binding.
Mandatory
transactionFlow="false"
InvalidOperationException will be throw when service binding disables at binding level. 
FaultException will be thrown when client disable at its binding level.



Transaction Protocols:

As a developer we no need to concern about transaction protocols and transaction manager used by WCF. WCF itself will take care of what kind of transaction protocols should be used for different situation. Basically there are three different kinds of transaction protocols used by WCF.



No comments:

Post a Comment