BizTalk supports two types of transactions namely Atomic & Long Running (L-R).Atomic transaction by nature does support ACID & Long Running (L-R) Transaction doesn’t support Classic ACID transaction. Hoping that you guys know ACID, but let me recap quickly ACID (Atomicity, Consistency, Isolation and Durability)
Atomic = All or nothing, either all the actions happen or none.
Consistent = The transaction as a whole is a correct transformation of the database.
Isolated = Each transaction runs as though there are no concurrent transactions.
Durable = The effects of committed transactions survive failures.
And it was expressed in very elegant mathematical theory of serializability and the Influence of the theory and the practical mechanism was recognized in the year 1998 by turning award to Jim Gray (70s he was responsible for some of the most fundamental work on database theory and practice)
Back to L-R Transaction, within the context of BizTalk Server an L-R transaction supports Consistency and Durability but not Atomicity and Isolation.This is true in a way since L-R decomposable into a number of inner transactions in which some or all may be ACID transactions and failed transaction can be rolled back in the normal way, but if previous ACID transactions might already been committed then it is too late to roll back.Which can be mitigated by the concept called compensation handlers, In which each inner transaction is provided with its own compensation handler. In the event of a failure the inner transaction's compensation executed and transaction will be rolled back, since we can’t roll back committed transactions so each compensation handler must do some action which can cancels or reverses the effect of its associated transaction which is nothing but backwards recovery. In some scenarios we can’t fully reverse the effect like email out so compensation doesn’t guarantee 100% recovery.
Assume that we have Transaction A, Transaction B, Transaction C & Transaction D and hit with error at Transaction C, now compensation come into picture to perform backwards recovery. Now forward recovery begins at transaction B what if error again hit at Transaction C it will go into backwards recovery again, which might lead into endless loop of recovery.To avoid this we need to implement exception handling saying that after N number of tries stop the recovery and exit from the loop.
