Shulou(Shulou.com)06/02 Report--

This article introduces you how to achieve a general distributed transaction framework based on TCC, the content is very detailed, interested friends can refer to, hope to be helpful to you.

A TCC transaction framework needs to address, of course, the management of distributed transactions.

Although the TCC transaction model is simple to say, it is much more complex to implement a general distributed transaction framework based on TCC than it looks. It is not just a simple call to Confirm/Cancel business.

The editor will take the Spring container as an example to try to analyze some of the problems that need to be paid attention to in implementing a general TCC distributed transaction framework.

1. TCC global transactions must be based on RM local transactions

TCC service is composed of Try/Confirm/Cancel service. When the Try/Confirm/Cancel service is executed, it will access the resource manager (Resource Manager, hereinafter referred to as RM) to access data.

These access operations must participate in RM local transactions so that the changed data is either commit or rollback.

This is not difficult to understand. Consider the following scenario:

Assuming that Service B in the figure is not based on RM local transactions (for example, RDBS can be simulated by setting auto-commit to true), if the [B:Try] operation fails and the TCC transaction framework later decides to roll back the global transaction, the [B:Cancel] needs to determine which operations in [B:Try] have been written to DB and which operations have not been written to DB.

Suppose the [B:Try] business has five write database operations, and the [B:Cancel] business needs to determine whether these five operations are valid one by one, and perform reverse operations on the operations that are in effect.

Unfortunately, because [B:Cancel] business also has n (00) times, the impact is the same. However, the effects of unexecuted and executed are definitely different, which does not belong to the category of idempotence.

6. Cancel business is parallel to Try service, even before Try operation.

This should be an incredible trap unique to the TCC transaction mechanism.

Generally speaking, the Try operation of a particular TCC service should be performed before its Confirm/Cancel operation.

After the execution of the Try operation, the Spring container instructs the TCC transaction framework to commit / roll back the global transaction based on the execution of the Try operation. Then, the TCC transaction framework invokes the Confirm/Cancel operations of each TCC service one by one.

However, with the existence of failures such as timeouts, network failures, and server restart, this order will be disrupted. For example:

In the figure above, assuming that the network is broken during the execution of the [B:Try] operation, [A:Try] will receive a RPC remote call exception.

If A does not handle the exception, the global transaction decides to roll back, and the TCC transaction framework will call [B:Cancel]. At this time, the network between An and B has been restored. If the [B:Try] operation takes a long time (network blocking / database operation blocking), there will be parallel processing of [B:Try] and [B:Cancel], or even the phenomenon that [B:Cancel] is completed first.

In this case, because [B:Try] is not yet in effect when [B:Cancel] is executed (its RM local transaction has not been committed), [B:Cancel] cannot be executed, or at least cannot take effect (rollback even if its RM local transaction is executed).

However, when [B:Cancel] finishes processing (skips execution, or rollback its RM local transaction after execution), the [B:Try] operation completes and takes effect again (its RM local transaction is successfully committed), which makes [B:Cancel] provide, but does not play the role of withdrawing [B:Try], resulting in data inconsistency.

So, in this case, the TCC framework needs to:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Mark the local transaction of [B:Try] as rollbackOnly to prevent it from coming into effect later.

Prohibit it from passing the transaction context to other remote branches again, otherwise the problem will occur on other branches

Accordingly, [B:Cancel] does not have to be implemented, at least not in effect.

Of course, the TCC transaction framework can also simply choose to block the processing of [B:Cancel], and then determine whether it needs to execute [B:Cancel] according to its execution after the execution of [B:Try].

However, this kind of treatment will be less efficient because it needs to wait.

The same thing can happen in confirm business, except that the processing logic that occurs in Confirm business is different from that in Cancel business.

The TCC framework must ensure that:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Confirm service executes after Try service. If parallelism is found, it can only block the corresponding Confirm business operation.

After entering the Confirm execution phase, you can no longer commit RM local transactions for new Try operations within the same global transaction.

7. Is the reusability of TCC services relatively poor?

The definition of TCC transaction mechanism determines that a service needs to provide three business implementations: Try service, Confirm service and Cancel service.

As a result, some people may think that TCC services are less reusable. How to say, if the Try/Confirm/Cancel business logic is taken out separately for reuse, its reusability is certainly not good.

As a part of TCC service, Try/Confirm/Cancel logic cannot be reused as a single component. Try, Confirm, Cancel business together constitute a component, if you want to reuse, it should be to reuse the entire TCC service component, not a separate Try/Confirm/Cancel business.

Does the TCC service need to expose three service interfaces?

I don't need it. Like ordinary services, TCC services only need to expose one interface, that is, its Try business.

Confirm/Cancel business logic is provided only because of the need for global transaction commit / rollback, so Confirm/Cancel business only needs to be discovered by the TCC transaction framework and does not need to be perceived by other business services that call it.

In other words, when other services of a business system need to invoke a TCC service, they don't need to know whether it is a TCC service at all.

Because, TCC services can be invoked by other business services only its Try business, Confirm/Cancel services can not be directly invoked by other business services.

9. Can the Confirm/Cancel business of TCC Service An invoke the Confirm/Cancel business of TCC Service B that it depends on?

It's best not to do this.

First of all, it is not necessary. TCC Service A relies on TCC Service B, so [A:Try] has propagated the transaction context to [B:Try], and then the TCC transaction framework can invoke their respective Confirm/Cancel services.

Second, if the Confirm/Cancel business is allowed to invoke other services, it is possible to initiate a new TCC global transaction again. If this recursion goes on, the global transaction relationship will be confused and uncontrollable.

TCC global transactions, you should try to propagate the transaction context during the Try operation phase. In the Confirm/Cancel operation phase, you only need to complete the confirmation operation / compensation operation of the respective Try business operations, which is not suitable for remote calls, let alone publicize the transaction context.

On how to achieve a general distributed transaction framework based on TCC to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.