Distributed consistency Algorithm (vii) Implementation scheme of distributed transaction: TCC

Source: Internet
Author: User
Tags commit rollback

Reprint: A talk about the distributed transaction TCC transaction

Reproduced:

Reprint: First, the meaning of TCC

The TCC corresponds to try, Confirm, and Cancel three operations, the business meaning of these three operations is as follows: Try: Reserve Business Resources Confirm: Confirm execution of business actions cancel: Canceling business operations

A slight comparison of the three operations of relational database transactions:DML,Commit , and Rollback, will find a similar idea to TCC.

In a cross-application business operation, theTry operation is to reserve and lock the business resources in multiple applications first, laying the groundwork for subsequent confirmations, similar to theDML operation to lock the database record rows and hold the database resources ;Confirm The action is confirmed after all the applications involved in the try operation have been successful, using the reserved business resources, similar to Commit , and cancel is when all the apps involved in the try operation are not all successful and need to cancel the successful app ( That is, rollback rollback). Where the confirm and cancel operations are a pair of reverse business operations. In short, theTCC is 2PC (2 Phase Commit, two-phase commit) of the application layer, if you consider the application as a resource manager. ii. differences between TCC and XA The TCC transaction mechanism is relative to the traditional transaction mechanism (X/open XA), which is characterized by the fact that it does not rely on resource Manager (RM) support for XA , but rather through the scheduling of business logic (provided by the business system) to implement distributed transactions.

For a particular business logic s in a business system, it must accept some uncertainty when it provides services externally, that is, a call to the business logic is only a temporary operation, and the consumer service m that invokes it retains the subsequent cancellation rights . If M thinks the global transaction should be rollback, it will require that the previous temporary operation be canceled, which corresponds to a cancel operation of S. When M considers the global transaction to be a commit, it discards the cancellation rights of the previous temporary operation, which corresponds to a confirmation operation of S. Each initial operation will eventually be confirmed or canceled. Therefore, for a specific business service, the TCC transaction mechanism requires the business system to provide three segments of the business logic : Preliminary operation try, confirm Operation confirm, cancel operation of Cancel.
1. Preliminary operation (Try)
The business logic (Try) in the TCC transaction mechanism, as seen in the execution phase, is the same as the business logic in the traditional transaction mechanism. But from a business point of view, it is not the same . The try in the TCC mechanism is only a preliminary operation, which together with subsequent confirmations can truly constitute a complete business logic. Therefore, it can be considered that

[traditional transaction mechanism] business logic = [TCC transaction Mechanism] preliminary operation (Try) + [TCC transaction mechanism] acknowledgment logic (Confirm).

The TCC mechanism divides the business logic in the traditional transaction mechanism into half, the part that is retained after the split is the preliminary operation (Try), and the isolated part is the acknowledgment operation (CONFIRM), which is deferred to the transaction commit phase.
The TCC transaction mechanism is centered on the preliminary operation (try), and both the acknowledgment operation (Confirm) and the Cancel operation (cancel) are carried out around the preliminary operation (try). Therefore, the action in the try phase, its supportability is best, even if it fails, there is still cancel operation (cancel) can be the adverse effect of the drawdown.
2. Confirm Operation (CONFIRM)
The Confirm operation (Confirm) is a supplement to the preliminary operation (Try). When the TCC transaction manager considers that the global transaction can be committed correctly, the confirmation action (Confirm) specified in the preliminary operation (try) is performed one by one, and the initial action (try) unfinished matter is finalized.
3. Canceling the operation (cancel)
The cancel operation is a drawdown of the preliminary action (Try). When the TCC transaction manager considers that the global transaction is not committed correctly, the cancel operation (cancel) specified in the preliminary operation (try) is performed one by one, and all the actions completed by the preliminary operation (try) are withdrawn.

In the traditional transaction mechanism, the execution of business logic and the processing of transactions are handled by different parts at different stages : The business logic partially accesses the resource to realize the data storage, its processing is the responsibility of the business system, and the transaction part is managed by coordinating the resource manager to realize the transaction management. Its processing is the responsibility of the transaction manager. There is not much interaction between the two, so the transaction logic of the traditional transaction manager only needs to focus on the transaction completion (commit/rollback) phase, rather than the business execution phase . The relationship between business logic and transaction processing in the TCC transaction mechanism is complicated: the business logic (TRY/CONFIRM/CANCEL) phase involves the commit/rollback of participating resource transactions; global transaction commit/ Rollback also involves the execution of business logic (Try/confirm/cancel).

Third, the realization of TCC

TCC currently has the following types of open source implementations:

1. Tcc-transaction distributed TCC-type transaction framework, GIT address: https://github.com/changmingxie/tcc-transaction

2. Atomikos proposed a RESTful TCC compensation mode based on HTTP, actual combat address: HTTPS://GITHUB.COM/PRONTERA/SPRING-CLOUD-REST-TCC

3. BYTETCC Distributed transaction Manager, git address: Https://github.com/liuyangming/ByteTCC/wiki

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.