A brief history of extended transactions

Summary

Atomic transaction processing is a widely known technique for ensuring consistency in the event of a failure. The ACID properties of atomic transactions ensure that state consistency is maintained in even complex business applications, regardless of concurrent access and failure. However, while this is an extremely useful fault-tolerant technique, it is not sufficient to meet the needs of long span transactions. Because of the long span of transactions, the relaxation of transaction attributes is necessary. The so-called extended transaction processing model has been around for many years, but until the advent of Web services, they tend to remain in academic research environments. In this article, we examine these requirements and examine how the industry standard for extended transactions developed under CORBA's tightly coupled environment has greatly impacted the loosely coupled environment of web services.

Introduction

Distributed systems make the reliability problems that are uncommon in centralized systems to be highlighted. Distributed systems are made up of computers that are heavily connected to a network, and often suffer from any of these child parts, such as the computer itself, the network connection, the operating system, or individual applications, and some behavioral activities that are not determined by the execution time. Going to the center allows one part of the entire system to fail, while the other part remains running. However, this can lead to the possibility of abnormal behavior during execution of the program. After the advent of the Web service, the service provider who wanted to take advantage of this huge business-to-business space swarmed. However, the Web is the largest distributed system ever, and failures occur that affect the performance and consistency of applications running on the web.

Atomic transaction processing is a widely known technique for ensuring consistency in the event of a failure [1]. Its ACID properties ensure that state consistency is maintained in even complex business applications, regardless of concurrent access and failure. This is an extremely useful fault-tolerant technique, especially if it involves multiple resources (possibly remote resources).

However, since Web services have evolved into a way of integrating processes and applications across enterprise levels, the semantics and protocols of traditional transaction processing have proved outdated. The difference between a Web service based transaction and a traditional transaction is that the former has a long execution cycle, requiring that the commit of the transaction be "negotiated" at run time, and the isolation level must be relaxed. The so-called extended transaction processing model has been around for many years, but until the advent of Web services, they tend to remain in academic research environments. However, the OASIS Web Services Services (WS-TX) Technical Committee is developing a standard [2] for Web service transaction management, which uses an extended transaction processing model. In this article, we will first consider why traditional atomic transactions are not sufficient to meet the needs of long cycle activities, and secondly, we will build on the research and development work done by the OMG before the advent of Web services, detailing how WS-TX solves these problems.

Why do I need to extend the transaction processing model?

For many years, distributed objects coupled with acid transactions have built the foundation for creating highly-integrated business applications. The ACID properties of transactions to ensure that the application's state consistency is maintained even in complex business applications, regardless of concurrent access and failure. Transactions can be terminated in two ways: committed or aborted (rolled back). When a transaction is committed, all changes in its process are persisted (stored on a stable storage device, such as a disk). When a transaction is aborted, modifications made in the transaction lifecycle are revoked.

The traditional transaction system uses a two-phase protocol to ensure the atomic implementation between the participants, Figure 1: In the first (prepare) phase, a separate participant must persist the change in each state in the scope of the transaction so that, once the transaction results are determined, the changes can be rolled back or committed. Assuming that there are no failures in the first phase, participants can "overwrite" the original state by using the state of the first stage persistence in the second (commit) phase.

Figure 1: Two-phase commit protocol

To ensure consistency, two-phase commit must be a blocking protocol: After the first phase of the response is returned, each participant who returns a submit response must remain blocked until a second stage message from the coordinator is received. All of the resources used by the participant cannot be used by other transactions until they receive the message, or they can cause the non-ACID behavior to occur. If the coordinator fails before the second phase of the message is sent, the resources remain blocked until the coordinator completes the recovery.

Majority opinion Group (Consensus groups)

It has long been recognized that the acid transaction itself is not sufficient to construct long running applications [3][4]. One of the notable improvements (supported by the CORBA object Transaction Service OTS [5]) is to allow for the nesting of transactions, in addition, nested transactions can be concurrent. In this hierarchy, the outermost transaction is generally referred to as the top-level transaction. The persistence attribute can only be owned by the top-level transaction, and the commit of the nested transaction (child transaction) is temporary relative to the commit or abort of the outer transaction. This takes into account the specifics of the fault-control policy, which means that the error of the child transaction does not necessarily cause an error in its outer transaction. A resource obtained in a child transaction is inherited (reserved) by its parent firm when it is committed, and is only released when the top-level transaction completes (assuming no failure occurred). In other words, these resources will be held until the end of the top-level transaction.

The above improvements can be satisfied when application functionality can be represented as a single top-level transaction. But that's often not the case. Top-level transactions are best regarded as "short-lived" entities, with stable state changes to the system [4]; they are less suitable for constructing long-lived application features (for example, running hours or even days). Long-span top-level transactions can reduce the concurrency of the system to unacceptable levels because of the long time consuming some resources; Moreover, if such a transaction is aborted, many of the valuable work previously done can be undone. In short, if an application is made up of a series of transactions, the entire activity of the running application during runtime is frequently required to relax some of the acid properties for each transaction. As a result, the entire activity can be viewed as a non-acid "extended transaction".

The scope of the control model [6] Describes the fundamental concepts of recovery and submission in extended transaction processing. In the development of specific extended transaction processing models, many studies have been conducted [for example 7-10], focusing on the opinions of the majority opinion group. Not all participants in a particular extended transaction must get the same result; a specific transaction might have multiple different majority groups, with different results for each group of participants. In addition, in some majority opinion groups it may be allowed to relax the atomic limits of a particular transaction, allowing a subset of the participants to get a different result. This flexibility in the list of participants in a group is an important difference between these types of extended transactions and traditional transaction systems.

Furthermore, participants should be able to withdraw from a majority opinion group if necessary. There are many reasons why participants may no longer wish to participate in the majority opinion group: for example, the work that it completes can safely end without taking into account the final outcome of the majority opinion group, or another independent task (a different service or domain) may be necessary to perform a reverse effect when the majority opinion group cancels the work.

The majority opinion group achieved consistent results among the participants, but they were only the tip of the iceberg. In Business-business (business-to-business) relationships, there is often a hierarchical relationship between these groups (the scope of work), where the parent-child relationship is included between these hierarchical relationships. In general, validation or cancellation of completed work within the business transaction process means that the participants will make the decision. For example, an application might choose to perform changes as a temporary effect and make them visible to other business transactions. At the same time, the application may store the necessary temporary information to undo these changes. When it is confirmed, it can simply discard the revocation information, or, in the case of cancellation, it can apply these undo changes. For example, an application can take a scheme similar to that based on compensation, or a traditional "rollback" approach.

In addition to understanding these results, participants within the business transaction process may need to support temporary or attempted state changes during transaction processing. These Parties (parties) must also support the completion of business transactions by confirming (the final effect) or canceling (counter-productive). In general, validation or cancellation of completed work within the business transaction process means that the participants will make the decision. For example, an application might choose to perform changes as a temporary effect and make them visible to other business transactions. At the same time, the application may store the necessary temporary information to undo these changes. When it is confirmed, it can simply discard the revocation information, or, in the case of cancellation, it can apply these undo changes. For example, an application can take a scheme similar to that based on compensation, or a traditional "rollback" approach.