BizTalk orchestration provides a transactional programming model that includes support for exception handling and recovery from failed transactions. Orchestration can include one or more transactions.
Unlike traditional programming, BizTalk Server supports two distinct types of transactions: atomic and long-running.
You can set an orchestration with the transaction type at the orchestration level or if you need a finer level of granularity for configuring transaction behavior, you can define a construct known as a scope to wrap a unit of work within a transaction boundary.
In order to understand the two different types of transactions in BizTalk, let me review traditional (or classic) transaction concepts. Traditional transactions possess several characteristics that can be described by using the ACID acronym:
- Atomic. All activities that are part of the transaction boundary complete as a unit of work.
- Consistent. Any work resulting in changes to data (presumably within a database or in-memory objects) must be left in a consistent state regardless of transaction outcome. Should the transaction abort, the data is returned to the state it was in prior to the transaction.
- Isolated. Changes to the state of objects are isolated within the unit of work such that concurrent access to the data being operated on is unambiguous.
- Durable. The changes as a result of a committed transaction persist even in the event of a system failure.
ACID transactions have long been the staple of reliable database programming. Component-oriented technologies such as COM+ and .NET bring ACID transactions to the middle tier courtesy of the Microsoft Distributed Transaction Coordinator (DTC) and the System.Transactions namespace in .NET 2.0. As any experienced database or system developer knows, you must take great care in instrumenting ACID transactions. The unit of work within an ACID transaction must happen as quickly as possible due to the fact that maintaining isolation within transactions is both resources intensive and often requires exclusive read and/or write access to the underlying objects or data structures. That said, ACID transactions are a critical requirement for applications that require any degree of reliability and data integrity.
- Enables a transaction to automatically roll back to a previous state in case the transaction does not successfully complete.
- Supports ACID, in BizTalk, you can design orchestrations to support ACID transactions by configuring the scope (or the entire orchestration itself) as atomic. Any variables, messages, etc., within an atomic scope, are isolated within the transaction and changes to their state are not visible until after the transaction commits. Atomic transactions are married with the appropriate isolation level. Choices include serializable (object-level locking), read committed (only committed data is readable) and repeatable read (row-level locking occurs to prevent “dirty” reads).
It is important to understand that if an orchestration is marked as atomic, the initiating message will not be removed from the MessageBox until the transaction commits. In addition, any work performed within an atomic scope by .NET components will not participate in the transaction unless the .NET component inherits from System.EnterpriseServices.ServicedComponent and is transaction-aware. In this case, the .NET component will be enlisted as part of a COM+ DTC-style transaction and will participate as expected in a two-phased commit. This distinction is very important because the work performed by vanilla .NET components will be persisted regardless of the outcome of the transaction.
- Can span days, weeks, and longer time durations, contain nested transactions, and use custom exception handling to recover from error scenarios.
- Supports Consistency and Durability
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.
Another common scenario is a business process that might take seconds, minutes or even days or weeks to complete. This is when a long-running transaction is more suitable.
- Atomic supports ACID
- Long-Running supports Consistency and Durability