This is the 22nd day of my participation in Gwen Challenge

TCC premise background

About the concept of TCC (try-confirm-cancel), It was first proposed by Pat Helland in a paper titled Life Beyond Distributed Transactions: An Apostate’s Opinion published in 2007. In this paper, TCC was still named fay-confirmation Cancellation. The official name for try-confirm-Cancel is probably an introduction to TCC by Atomikos (Gregor Hohpe’s book Enterprise Integration Patterns), Mentions Atomikos’ try-confirm-cancel and thinks they are similar concepts).

Corresponding implementation schemes and open source frameworks have also been published, and ByteTCC is one of them.

Study with questions

  1. How to implement TCC distributed transaction processing. How to understand the TRYING, CONFIRMING, and CANCELIING of TCC. What about idempotence?

TCC concept introduction

Compared with traditional transaction mechanism (X/Open XA two-phase-commit), TCC transaction mechanism is characterized in that it does not rely on resource manager (RM) support for XA, but implements distributed transactions by scheduling business logic (provided by business systems).

While the TCC transaction model is simple to say, implementing a general distributed transaction framework based on TCC is more complicated than it seems, requiring a simple call to Confirm/Cancel.

  • For a specific business logic S in the business system, it must accept some uncertainties when providing services externally, that is, a call to the business logic is only a temporary operation, and the consumer service M that calls it reserves the right to cancel subsequent operations.

  • If M thinks the global transaction should be rollback, it will ask to cancel the previous temporary operation, which will correspond to a cancel operation of S. When M decides that the global transaction should be committed, it waives the right to cancel the previous temporary operation, which corresponds to a confirmation operation of S.

  • Every initial action will eventually be confirmed or cancelled. Therefore, for a specific service, the TCC transaction mechanism requires the service system to provide three segments of business logic: initial operation Try, Confirm operation, and Cancel operation Cancel.

TCC structure analysis

Initial operation (Try)

The business logic (Try) in THE TCC transaction mechanism is the same from the execution stage as in the traditional transaction mechanism. But from a business perspective, it’s different. The Try in the TCC mechanism is an initial operation that, along with subsequent validation, really constitutes a complete business logic. You can think

[Traditional transaction] business logic = [TCC transaction] initial operation (Try) + [TCC transaction] confirmation logic (Confirm).

The TCC mechanism divides the business logic in the traditional transaction mechanism into two parts. The part retained after splitting is the initial operation (Try). The separated part, the confirmation, is deferred until the transaction commit phase.

  • The TCC transaction mechanism is try-centric. Confirm and Cancel are both performed around a preliminary Try.

  • An operation in the Try phase is the best guaranteed, and even if it fails, there is still a Cancel operation to undo its ill effects.

Confirm operation

Confirm is a complement to the initial Try. When the TCC transaction manager decides to commit a global transaction, it performs the confirmations specified by the initial Try, finalizing what the initial Try did not complete.

Cancel operation (Cancel)

A Cancel is a rollback of a preliminary Try. When the TCC transaction manager decides to rollback global transactions, it performs the Cancel specified by the initial Try operation one by one to rollback all the items that the initial Try operation has completed.

In the traditional transaction mechanism, the execution of business logic and transaction processing are completed by different components at different stages: the business logic part accesses resources to realize data storage, and its processing is responsible for by the business system;

The transaction processing part implements transaction management by coordinating resource managers, whose processing is handled by the transaction manager. There is not much interaction between the two, so the transaction logic of a traditional transaction manager only needs to focus on the commit/ ROLLBACK phase, not the business execution phase.

However, the relationship between business logic processing and transaction processing in TCC transaction mechanism is complicated.

  • The business logic (Try/Confirm/Cancel) phase involves commit/rollback of participating resource transactions.

  • Global transaction COMMIT/ROLLBACK involves the execution of service logic (Try/Confirm/Cancel).

TCC implementation principle

  • TCC global transactions must be implemented based on RM(Resource Manager) local transactions.

  • The TCC service consists of the Try, Confirm, and Cancel services. When the Try, Confirm, and Cancel services are executed, the TCC service accesses the Resource Manager (RM) to access data.

  • These access operations must participate in the RM local transaction to make the data they change either commit or rollback.

This isn’t hard to understand. Consider the following scenario:

Case scenario

Service B in the figure above is not based on RM local transactions (for example, RDBS, which can be simulated by setting auto-commit to true), so if [B:Try] fails midway and the TCC transaction framework decides to roll back the global transaction, The [B:Cancel] operation needs to determine which operations in [B:Try] have been written to the DB and which operations have not been written to the DB. Assume that the [B:Try] service has five write operations to the database. The [B:Cancel] service needs to determine whether the five operations take effect one by one and reverse the effective operations.

No RM is false

Unfortunately, since [B:Cancel] also has n (0<=n<=5) reverse write operations, if [B:Cancel] also fails, the subsequent [B:Cancel] execution will be more onerous.

Compared with the first [B:Cancel] operation, the subsequent [B:Cancel] operation also needs to determine which of the n (0<=n<=5) write libraries of the previous [B:Cancel] operation have been executed and which have not been executed, which involves idempotent problems.

The guarantee of idempotent may also involve additional write library operations, which will have similar problems due to the lack of RM local transaction support. It is conceivable that TCC transaction framework cannot effectively manage TCC global transactions without RM local transactions.

On the other hand, TCC transactions based on RM local transaction can be easily handled: [B:Try] operation fails in the middle, TCC transaction framework can participate in RM local transaction rollback.

Later, when the TCC transaction framework decides to rollback the global transaction, it does not need to perform the [B:Cancel] operation when it knows that the RM local transaction involved in the [B:Try] operation has rolled back.

In other words, when implementing the TCC transaction framework based on RM local transactions, the Cancel business of a TCC service either executes or does not execute, regardless of the partial execution.

Student: TCC is 2PC?

“TCC is a two-phase submission?” . One possible reason is that TCC splits the business logic into try, confirm, and Cancel execution in two different phases.

In fact, this statement is not correct. The prepare and COMMIT phases of the two-phase commit mechanism are confused with the try and confirm/cancel execution phases of the TCC mechanism. This is probably because I do not understand the two-phase commit mechanism and TCC mechanism.

Reasons why

2PC mechanism

A two-phase Commit (2PC for short) consists of Two phases: Prepare and Commit. Its transaction processing mode is as follows:

  1. When global transaction decisions are committed, a) send prepare requests to RM one by one; B) If all RMS return OK, send commit requests one by one to commit the transaction; Otherwise, send rollback requests one by one to rollback the transactions.

  2. When a global transaction decides to rollback, simply send the rollback requests one by one instead of in stages.

Note that the 2PC mechanism requires RM to provide underlying support (generally XA-compatible), while the TCC mechanism does not.

TCC mechanism

Try-confirm-cancel (TCC) divides the service logic into two phases: Try, Confirm, and Cancel. For details, see INTRODUCTION to TCC Transaction Mechanism.

Its transaction processing mode is as follows:

  1. When the global transaction decision is committed, the confirm business logic corresponding to the try business logic is called;
  2. When the global transaction decides to roll back, the cancel business logic corresponding to the try business logic is called.

As you can see, TCC transactions are very simple: either the Confirm business logic is called or the Cancel logic is called.

Why is the try business logic not mentioned here? Because try logic has nothing to do with global transaction processing.

When we talk about 2PC, we only focus on the transaction phase, so we only talk about prepare and COMMIT, so there is also a business logic phase when using 2PC transaction management mechanism.

It is the execution of the business logic that initiates the global transaction that leads to the subsequent transaction processing phase. In fact, when using the 2PC mechanism, take commit as an example.

A complete transaction life cycle is: begin -> Business Logic -> Prepare -> COMMIT.

To initiate a global transaction, it must also be done by executing a piece of business logic.

  • The business logic triggers the creation of TCC global transactions by executing;

  • Second, it also needs to perform partial data write operations;

In addition, you register yourself with the TCC global transaction by executing it so that subsequent TCC global transactions commit/ ROLLBACK can call back their corresponding Confirm/Cancel business logic.

So, using the TCC mechanism, for commit, a complete transaction lifecycle is: BEGIN -> business logic (try business) -> COMMIT (comfirm business).

To sum up, we can make a one-to-one correspondence between the two from the execution stage:

  1. The service phase of 2PC is equivalent to the try service phase of TCC.
  2. The prepare and Commit phase of 2PC is equivalent to the Confirm phase of TCC.
  3. Rollback for 2PC is equivalent to cancel for TCC.

conclusion

Although there are two phases in the TCC mechanism where business logic is executed, the try business phase is actually independent of global transaction processing. With this in mind, when comparing TCC with 2PC, it is easy to see that TCC is not a two-phase commit, but rather that it commits/rolls back the transaction by performing a piece of confirm/ Cancel business logic, and nothing more.

References:

www.infoq.com/cn/intervie… Cs.brown.edu/courses/cs2… www.enterpriseintegrationpatterns.com/patterns/co…