這篇文章就講解一些使用要避免使用tcc的一些坑。
但在實際開發首先還是看如何減少業務邏輯的複雜度，盡量避免使用tcc進行分布式事務管理，因為使用了tcc就說明業務本身有些複雜，畢竟需要呼叫多個其他服務進行增、刪、改處理。
@compensable(confirmmethod = "confirmmakepayment", cancelmethod = "cancelmakepayment", asyncconfirm = false,transactioncontexteditor = dubbotransactioncontexteditor.class, delaycancelexceptions = )
public void makepayment(string orderno, bigdecimal redpacketpayamount, bigdecimal capitalpayamount)
2.無法正常confirm和cancel就會導致，事務記錄資料無法被正常刪除，事務記錄數越來越多通過補償事務通過該定時從庫裡面查詢該資料，會導致跑定時時新生代使用激增，頻繁的ygc造成程式的吞吐量減少。
@compensable(confirmmethod = "confirmrecord", cancelmethod = "cancelrecord")
public string record(capitaltradeorderdto tradeorderdto)
它自己便生成root型別的事務。
造成的影響是：由於自己是root型別事務，前乙個方法paymentserviceimpl.makepayment生成root事務無法對其進行confime或cancel事務管理，後乙個方法redpackettradeorderservice.record()丟擲異常，它也不會回滾。它按照自己的邏輯處理，try方法成功就commit呼叫confirm方法，失敗則rollback呼叫cancel方法，其他的與我無關。
該方法會被呼叫兩次，由於主事務儲存著該方法的dubbo**介面方法，主事務會兩次呼叫它，第一次try方法呼叫，第二次為commit或cancel方法時呼叫
// @compensable
public string record(capitaltradeorderdto tradeorderdto);
與上面案例的區別是，主事務沒有儲存該方法dubbo**介面方法，主事務只會在try方法呼叫它一次。
以上就是不同的配置帶來的不同問題，正常邏輯要保證主事務管理呼叫的各個節點的事務，但錯誤的配置會改變管理的邏輯，從而產生異常。以上問題都能通過官網提供的例子進行復現，本文章講解主要是用了dubbo相關的案例。
解讀tcc transaction 分布式事務專案
原理 通過切面做事務排程，通過zk jdbc redis filesystem做的事務控制，可以自配 核心類 transactionrepository 事務資源控制 compensabletransactionaspect 事務排程切面 resourcecoordinatoraspect 事務資源...
python避坑 python避坑指南，持續更新
python安裝，匯入，和使用避坑指南，持續更新 bestmrright原創 因為python庫太多，開發者眾多，有些庫引用了其他庫，隨著其他庫不斷更新，有些類和方法會修改，有些庫作廢，有些庫被收入進python，所以使用時候經常有坑需要迴避。在此建貼，持續更新，以便後來者避坑，希望來著補充。安裝坑...
巧用執行緒避鋒芒
嘿嘿，大量執行緒執行任務，可以使任務速度加快，可能是執行執行緒的主要原因？本人初學，感覺如此。不過近日在反思中想到，在windows窗體程式設計中，執行緒的別種功效 可以使具有大運算量的程序易於控制。比如帶有死迴圈的方法通常使窗體及其控制項處於不可用狀態，怎麼辦呢？此時就應該使用新執行緒來運算死迴圈...