February 27, 2021
Hot Topics:

The Business Transactions Protocol

  • By Mark Little
  • Send Email »
  • More Articles »

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 [1]. 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 [2]; 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.

Two-phase commit protocol

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.

Page 1 of 4

This article was originally published on May 13, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date