The Business Transactions Protocol
With the advent of Web Services, the Web is being populated by service providers who wish to take advantage of this large B2B space. However, there are still important security and fault-tolerance considerations, which must be addressed. One of these is the fact that the Web frequently suffers from failures, which can affect both the performance and consistency of applications run over it.
Atomic transactions are a well-known technique for guaranteeing consistency in the presence of failures . The ACID properties of atomic transactions (Atomicity, Consistency, Isolation, Durability) ensure that even in complex business applications consistency of state is preserved, despite concurrent accesses and failures.
The structuring mechanisms available within atomic transaction systems are sequential and concurrent composition of transactions. These mechanisms are sufficient if an application function can be represented as a single atomic transaction. Transactions are most suitably viewed as "short-lived" entities; they are less well suited for structuring "long-lived" application functions (e.g., running for hours, days, and so on). Long-lived atomic transactions may reduce the concurrency in the system to an unacceptable level by holding on to resources (e.g., locks) for a long time; further, if such a transaction rolls back, much valuable work could be undone.
The OASIS Business Transactions Protocol ; specified by a collaboration of several companies, has tried to address this issue. In this paper we shall first consider why traditional atomic transactions are insufficient for long-running activities and then describe how the BTP has attempted to solve these problems.
Why ACID Transactions Are Too Strong
It has long been realised that ACID transactions by themselves are not adequate for structuring long-lived applications. To ensure ACID-ity between multiple participants, a typically two consensus mechanism is required, as illustrated in Figure 1: during the first (preparation) phase, a participant must make durable any state changes that occurred during the scope of the transaction, such that these changes can either be rolled back or committed later once consensus has been agreed amongst all participants, i.e., any original state must not be lost at this point as the transaction could still roll back. Assuming no failures occurred during the first phase, in the second (commitment) phase participants may "overwrite" the original state with the first phase state.
Figure 1: Two-phase commit protocol.
However, two-phase commit is a blocking protocol: after returning the phase 1 response, each participant which returned a commit must remain blocked until it has received the coordinator's phase 2 message. Until it receives this message, resources used by the participant are unavailable for use by other transactions. If the coordinator fails before delivery of the second phase these resources remain blocked until it recovers: all participants must see both phases of the commit protocol in order to guarantee ACID semantics.