Understanding and Implementing TCC Distributed Transactions with Python and DTM

Distributed transactions are needed when a business operation spans multiple databases or services, such as a cross‑bank transfer, where a single local transaction cannot guarantee ACID properties. The Try‑Confirm‑Cancel (TCC) pattern, introduced by Pat Helland in 2007, solves this by separating the operation into three phases.

The TCC workflow consists of a Try phase that performs business checks and reserves resources, a Confirm phase that finalizes the operation using the reserved resources without further checks, and a Cancel phase that releases resources if any Try fails. The pattern involves three roles: the Application (AP) that initiates the global transaction, the Resource Manager (RM) that handles branch resources, and the Transaction Manager (TM) that coordinates the global transaction.

To illustrate TCC, the article presents a micro‑service example of a bank transfer where the outbound and inbound services run in separate services. A sequence diagram (image) shows the interaction of Try, Confirm, and Cancel calls across these services.

The practical implementation uses Python with the @app.post decorators to define the Try, Confirm, and Cancel endpoints for both the outbound and inbound services. Each endpoint simply returns a JSON object indicating success:

@app.post("/api/TransOutTry")
def trans_out_try():
    return {"dtm_result": "SUCCESS"}

@app.post("/api/TransOutConfirm")
def trans_out_confirm():
    return {"dtm_result": "SUCCESS"}

@app.post("/api/TransOutCancel")
def trans_out_cancel():
    return {"dtm_result": "SUCCESS"}

@app.post("/api/TransInTry")
def trans_in_try():
    return {"dtm_result": "SUCCESS"}

@app.post("/api/TransInConfirm")
def trans_in_confirm():
    return {"dtm_result": "SUCCESS"}

@app.post("/api/TransInCancel")
def trans_in_cancel():
    return {"dtm_result": "SUCCESS"}

After defining the branch handlers, a global TCC transaction is started via a /api/fireTcc endpoint. The DTM service address and the business service address are configured, and the transaction calls the Try/Confirm/Cancel endpoints of both branches using t.call_branch :

# DTM service address
dtm = "http://localhost:8080/api/dtmsvr"
# Business micro‑service address
svc = "http://localhost:5000/api"

@app.get("/api/fireTcc")
def fire_tcc():
    gid = tcc.tcc_global_transaction(dtm, tcc_trans)
    return {"gid": gid}

def tcc_trans(t):
    req = {"amount": 30}
    t.call_branch(req, svc + "/TransOutTry", svc + "/TransOutConfirm", svc + "/TransOutCancel")
    t.call_branch(req, svc + "/TransInTry", svc + "/TransInConfirm", svc + "/TransInCancel")

Running the example requires launching the DTM server (Docker‑compose) and the Python service (Flask). The article provides the necessary shell commands:

# Deploy and start DTM (Docker >= 18)
git clone https://github.com/yedf/dtm
cd dtm
docker-compose up

# In another terminal, clone the sample
git clone https://github.com/yedf/dtmcli-py-sample
cd dtmcli-py-sample
pip3 install flask dtmcli requests
flask run

# Trigger the TCC transaction
curl localhost:5000/api/fireTcc

For rollback handling, the article shows how changing the TransInTry endpoint to return "FAILURE" causes the TM to invoke the Cancel phase on all branches, ensuring the global transaction is aborted. A second sequence diagram (image) visualizes this failure flow.

In summary, the article covers both the theoretical concepts of TCC and a complete hands‑on example, demonstrating successful commits and automatic rollbacks, giving readers a solid understanding of implementing TCC distributed transactions in backend services.