Fescar is derived from GTS (global transaction service), which has been on AliCloud since 2016. Right now it is at v0.2, and, according to their plan, still 2 major releases from GA

What problems do existing solutions have?

XA is the most common non-intrusive solution. However,

  • Need to be MySQL 5.7+
  • Long lock of txn resources
  • XA implmentations require heavyweight application server,.e.g, WebLogic/WebSphere

Common intrusive solutions has high dev costs:

  • reliable message delivery
  • TCC
  • Saga

What happens when you want to issue a new global txn?

Modules

  • Transaction Coordinator (TC) maintains the state of gloal txns.
  • Transaction Manager (TM) sends open/commit/rollback txn requests to TC
  • Resource manager (RM) maintains the branch txns
  1. TM sends the “open new global txn” request to TC. TC will generate a globally unique id, XID.
  2. XID will be passed along the microservice trace
  3. RM will register the branch txn with the same XID on TC
  4. TM will start the global commit or rollback
  5. TC will commit/rollback all branch txns under the same XID

The flow quite similar to XA’s, the key differences are:

  1. XA’s RM is on the DB layer. This RM is on the application layer
  2. Fescar commits directly during phase 1: it is not strictly 2PC! See below for rollback discussion

How is global rollback implemented?

RM writes the rollback log including the data before and after, and will commit the data update and rollback log in the same local txn.

When RM receives the rollback request from TC, it finds the local rollback log by XID and branch ID included in the rollback request, and execute the reversed SQL.

What is the isolation level?

TC will maintain a global exculsive write lock, by default it is read UNCOMMITED.

What if my resource does not support transaction natively?

Use the manual transaction(MT) mode. You need to implement your own prepre-commit-rollback APIs for 2PC.