2.1 Distributed Transaction Solution: 2PC

1. What Is 2PC?

A distributed transaction solution that guarantees strong consistency.

2. 2PC Process

• Divide the transaction into two phases:
  • Phase 1: the transaction manager sends prepare requests to all databases.
  • Phase 2 depends on the result of Phase 1.
    • If all responses in Phase 1 are ok, execute commit in Phase 2.
    • If one database responds fail in Phase 1, or the transaction manager times out while waiting, execute rollback in Phase 2.
• 

3. Use Cases for 2PC

• Suitable for businesses that require strong consistency, are highly time-sensitive, and whose distributed transactions can be rolled back, such as financial transfer scenarios.
• A single service uses multiple data sources and all data sources are DBs, that is, a traditional monolith.

4. Problems with 2PC

• Performance problem: in Phase 1, each database starts locking resources and does not release the locked resources until Phase 2. During this period it remains synchronously blocked, so performance is poor.
• Single-point problem: after Phase 1 is complete, if the transaction manager goes down during Phase 2, all databases cannot receive the next instruction and the transaction cannot continue.
• Consistency problem: after Phase 1 is complete, if any database goes down in Phase 2 and does not return an ACK, it is uncertain whether the other databases should commit or roll back.

5. Implementations of 2PC

• Each participant needs to implement three interfaces:
  • Prepare
  • Commit
  • Rollback

5.1. XA

• Databases have a unified standard for distributed transactions implemented based on 2PC, called DTP.
• The DTP model defines several roles:
  • AP: our microservice.
  • TM: global transaction manager.
  • RM: database.
  • CRM: communication middleware between TM and RM.
• In this model, one distributed transaction (global transaction) can be split into many local transactions running on different APs and RMs. The ACID properties of each local transaction are easy to implement, but the global transaction must guarantee that every local transaction it contains can succeed at the same time. If one local transaction fails, all other transactions must roll back. The problem is that while a local transaction is being processed, it does not know the running states of the other transactions. Therefore, CRM is needed to notify each local transaction and synchronize transaction-execution status.
• To allow different databases to communicate, there must be a standard, so XA was created. XA is the interface specification for communication between TM and RM.

5.2. Seata XA Mode

• Databases that support XA transactions.
• Java applications access the database through JDBC.

6. References

• If Someone Asks You About Distributed Transactions Again, Send Them This Article - Juejin
• Transactions - What Is the Difference Between TCC and 2PC? - SegmentFault
• What Is the Difference Between TCC and 2PC? - Zhihu
• Seata XA Mode