BizTalk Orchestration Transaction Types

BizTalk orchestration two transaction types for programming model i.e. Atomic and Long-Running and default option as "none".

Atomic Transaction: Atomic scopes come handy when you're creating an orchestration where actions must complete together or fail together. However, as mentioned before, atomic scopes may not contain nested atomic scopes or long-running scopes i.e. it fully satisfied ACID property.

ACID:

•     Atomicity
•     Consistency
•     Isolation
•     Durability

Atomicity means that you can guarantee that all of a transaction happens, or none of it does; you can do complex operations as one single unit, all or nothing, and a crash, power failure, error, or anything else won't allow you to be in a state in which only some of the related changes have happened.

Consistency means that you guarantee that your data will be consistent; none of the constraints you have on related data will ever be violated.

Isolation means that one transaction cannot read data from another transaction that is not yet completed. If two transactions are executing concurrently, each one will see the world as if they were executing sequentially, and if one needs to read data that is written by another, it will have to wait until the other is finished.

Durability means that once a transaction is complete, it is guaranteed that all of the changes have been recorded to a durable medium (such as a hard disk), and the fact that the transaction has been completed is likewise recorded.

Enables a transaction to automatically roll back to a previous state in case the transaction does not successfully complete.

ACID transactions are simply not appropriate is when the work to be done cannot be performed in a very short period of time. This condition is pervasive in modern Service-Oriented Architecture (SOA) applications where the unit of work to be performed can span multiple service endpoints. Maintaining highly disciplined services that are resilient to deadlocking issues is a challenge in itself, let alone when you have little or no control of the service being consumed itself.

Long Running Transaction: Long-running transaction scope similarly states that actions within your orchestration must either succeed or fail together, but here they may take a long time to complete. Upon failure, BizTalk offers you ways to enable compensation logic to suspend previous actions.

How could it be claimed, for example, that L-R transactions maintain consistency in the strong ACID sense in an environment where transactions are not isolated from each other and may take arbitrary times to complete, or may not complete at all?  Consistency, however, can be achieved in L-R transactions through the mechanism of compensation.  However, this offers a significantly 'weaker' (no flame mail, please - you all know what I mean) approach to maintaining consistency than using, say, serialized atomic transactions.

 "It only support Consistency and Durability of ACID property"

None Transaction: It only use when want to logged exception only just try to use scope and orchestration transaction type as None.

Note:  If you choose Atomic transaction type in orchestration property that means variables or another .net component either it is in scope or out side of scope will fully follow ACID property but if you choose only Atomic transaction type in a particular scope then ACID property will follow only that scope.

!! Keep visiting BizTalkLive !!