TCC Compensation mode Distributed transaction __ distributed based on RESTful API

Preface

This example is based on a Atomikos distributed transaction solution, built on a more lightweight HTTP protocol, which reads

TCC for transaction management across MicroServices

According to the try Confirm Cancel compensation mode, there are actual battles about spring cloud as follows

HTTPS://GITHUB.COM/PRONTERA/SPRING-CLOUD-REST-TCC Sample Scenario

A simple TCC application is as follows: In the figure blue box booking Process representative booking system, the system respectively to Swiss and easyjet to initiate the reservation ticket resources request

Initiate a try reservation request on "Swiss" in step 1.1. The service provider "Swiss" will wait for the confirm operation and, if it is timed out, will be automatically revoked (cancel) and the resource released. The entry of the confirmation resource is the HTTP put request of the URI R1.

In step 1.2, use URI R2 to make a reserved resource operation for "easyjet" as in 1th

In step 1.3, the booking process can now initiate a confirmation (Confirm) operation on both of these reserved resources through the Coordinator (Coordinator) service. Also, the Resource Coordination Service handles validation or compensation operations for related services.

If there is any exception before step 3rd, all reserved resources will be cancelled or wait for a timeout and then be automatically revoked. If an exception occurs after the 3rd step confirm, then all resources are unaffected. Exceptions that occur in step 3rd are handled by the Coordinator service, including recovery retries due to downtime or network jitter. Provides a transaction guarantee for rest services. role

This set of APIs consists of 3 roles: Participant roles, coordinator roles, and applications. Participants are specifically those that implement TCC flexible transactions, just as the "Swiss" and "easyjet" coordinator roles in this example refer specifically to those service calls that manage a group of related participants, such as confirm, Cancel, in this example, "Transaction Coordinator "application, which I call the requester, has no other requirements other than the need to use a coordinator, as in this example," booking Process " TCC Service provider: Contributor API contributor Responsibilities

Participants are responsible for managing specific business resources. By default, a business reservation resource times out after a certain amount of time, unless the reserved resource is confirmed by the coordinator. Auto Timeout and recall

The implementation of each participant must have the function of the automatic cancel timeout resource. No resources will expire unless the participant receives a confirmation message. access to resource operations

The implementation of each participant must return a link to invoke confirm. These links can include confirm URI, automatic expiration time, and so on metadata. Here is a simple example

{
  "Participantlink":
    {"uri": "http://www.example.com/part/123",
    "Expires": "2014-01-11t10:15:54z"
    }
}

In fact, the JSON in the example is only a suggested format, and the actual use depends entirely on the communication format of both parties. Put to Confirm

The Put method must be supported for confirmation in the link returned by the above participant for confirmation. Because of the network jitter and so on, the operation must have power.

put/part/123 http/1.1
Host:www.example.com
ACCEPT:APPLICATION/TCC

Note the MIME type in the request header, hinting at the client's semantic expectations (you can choose whether to implement the mediatype based on the actual situation). Confirm operations are usually invoked by the coordinator.

Although the API provided by the participant has a specified MIME type, this type is used only to indicate semantics and does not actually require the request body and response body.

If everything works, the response of the participants is as follows

http/1.1 204 No Content

If a confirm request is sent to the participant and the reservation resource is found to have been cancel or the timeout has been rolled back, the participant's API must return a 404 error

http/1.1 404 Not Found

DELETE to Cancel: optional implementation

Each participant uri** may be able to implement the Delete method to explicitly accept the revocation request. Because of the network jitter and so on, the operation must have power.

delete/part/123 http/1.1
Host:www.example.com
ACCEPT:APPLICATION/TCC

Returns if the compensation succeeds

http/1.1 204 No Content

Because participants have the responsibility to implement an automatic undo timeout resource, if there are other errors when the cancel is explicitly called, these errors can be ignored and do not affect the overall distributed transaction

After the internal transaction has timed out or has been compensated by the participant itself, then he can return directly to 404

http/1.1 404 Not Found

Because the delete request is an optional operation, some participants may not be able to implement this feature, in which case they can return 405

http/1.1 405 method is not allowed

Get Method Fault diagnosis: Optional Implementation

A participant service can implement a Get method for troubleshooting. But this is beyond the intent of the rest TCC Minimalist protocol, so this functionality is determined by the actual implementation of the Coordinator API: The requester-oriented developer

The Coordinator service is implemented by us and is used by developers of the requesting party. Because this is illustrated from the design perspective of using the RESTful interface, it does not discuss the internal implementation of the Coordinator. Coordinator Responsibilities initiate confirm requests for all participants whether it is a coordinator error or an error from the caller, the coordinator must have automatic recovery retry, especially during the confirmation phase. Be able to determine the cause of a problematic Confirm operation Easy Cancel operation put to Confirm

The requestor issues a put request to the coordinator to confirm the current distributed transaction. These transactions are confirmation links that are returned to the requester before the participant

Put/coordinator/confirm http/1.1
Host:www.taas.com
content-type:application/tcc+json
{
  " Participantlinks ": [
     {
     " uri ":" Http://www.example.com/part1 ",
     " Expires ":" 2014-01-11t10:15:54z "
     } ,
     {
     "uri": "Http://www.example.com/part2",
     "Expires": "2014-01-11t10:15:54+01:00"
     }
  ]
}

The coordinator then initiates a confirm request to the participant, and if all goes well, the following results will be returned

http/1.1 204 No Content

If the time to initiate a confirm request is too late, it means that all the passive parties have timed out compensation

http/1.1 404 Not Found

The worst case scenario is that some participants have confirmed it, but some have not. This situation should return 409, which is defined as a heuristic exception in Atomikos

http/1.1 409 Conflict

Of course, this should be avoided as much as possible, requiring confirm and Cancel to be idempotent, and when errors occur, the coordinator can retry the participant several times to minimize the chance of an illuminated anomaly occurring. In case 409 does occur, it should be the requester's initiative to check or return the detailed execution information to the requester by the Coordinator, such as a GET request to initiate a fault diagnosis for each participant, log the fault information, and manually intervene. Put to Cancel

A revocation request is similar to a confirmation request by using a put request, and the only difference is that the URI is different

Put/coordinator/cancel http/1.1
Host:www.taas.com
content-type:application/tcc+json
{
  " Participantlinks ": [
     {
     " uri ":" Http://www.example.com/part1 ",
     " Expires ":" 2014-01-11t10:15:54z "
     },
     {
     "uri": "Http://www.example.com/part2",
     "Expires": "2014-01-11t10:15:54z"
     }
  ]
}

The only predictable response is

http/1.1 204 No Content

Because the end of the reservation is released when the resource is not confirmed, the participant returns other errors that do not affect final consistency