When an orchestration fails halfway through, you can’t leave your data in a “half-baked” state. BizTalk provides three ways to manage state and recovery through Transaction properties on Scopes and Orchestrations. BizTalk orchestration provides a transactional programming model that supports exception handling and recovery from failed transactions. Orchestration can include one or more transactions.
Unlike traditional programming, BizTalk Server supports three distinct transaction types: none, 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.
📝 One-Minute Brief
BizTalk orchestrations support three main transaction types to ensure data consistency: None, Atomic, and Long-Running. Atomic transactions follow strict ACID properties and are ideal for short, isolated tasks like database updates. Long-Running transactions are designed for processes that span hours or days, utilizing custom “Compensation” blocks to undo actions if a failure occurs later in the process. This post breaks down when and how to use each to build resilient integrations.
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 within the transaction boundary are executed as a unit of work.
- Consistent. Any work that results in changes to data (presumably within a database or in-memory objects) must leave it in a consistent state regardless of the transaction outcome. Should the transaction abort, the data is returned to its state prior to the transaction.
- Isolated. Changes to the state of objects are isolated within the unit of work, ensuring concurrent access to the data being operated on is unambiguous.
- Durable. Changes resulting from 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 resource-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.
None (The Default)
Most simple orchestrations use None. There is no overhead, but there is no safety net either. If a shape fails, the orchestration simply suspends. Use this for stateless processes that don’t interact with external databases or systems requiring consistency.
Actually, while Long-Running transactions are common for complex logic, None (No Transaction) is arguably the most frequent setting used in high-volume, performance-driven integration processes.
When you set an orchestration or scope to None, you are opting for the fastest possible execution, as BizTalk doesn’t have to manage the overhead of ACID properties or state persistence for that specific block.
Atomic transactions
Atomic transactions are for short, “all-or-nothing” operations. They follow the ACID principle: Atomicity, Consistency, Isolation, and Durability.
- Behavior: If any part fails, everything inside the scope is rolled back automatically.
- Requirement: All variables and messages used inside must be Serializable.
- Best For: Database updates or calling a series of web services that must succeed together.
This transaction type:
- 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 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.
Long-running transaction
In the world of integration, a process might wait three days for a partner’s response. You cannot “lock” a database for three days.
- Behavior: These do not provide ACID isolation. Instead, they rely on Compensation. If a failure happens, BizTalk calls a specific “Compensation Block” where you write the logic to manually undo previous steps (e.g., sending a cancellation email).
- Best For: Complex business processes that include delays, human intervention, or multiple external systems.
This transaction type:
- 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 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 over 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.
In resume
- Atomic supports ACID
- Long-Running supports Consistency and Durability
If your goal is scalability and speed, start with None. Only move to Atomic or Long-Running transactions when the business logic absolutely requires ACID compliance or complex compensation.
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.
Can one use Transaction Type of Long Running to get round the Biztalk connection to the Database timimg out?
Thanks for the clear explanation, much better than the books I’ve been reading.