how two phase commit ensure serializability

Question

Two phase commit is used in distributed transaction. For example, a client sends a transaction to two databases with a coordinator.

• step1: client get a global transaction id from coordinator
• step2: client send the transaction to two databases respectively
• step3: client send the commit flag to coordinator
• step4: coordinator send prepare flag to two databases, and two databases response prepare ack
• step5: coordinator send commit flag to two databases, and two databases response commit ack
• step6: coordinator response commit ack to client

My questions are

• What is the global transaction id in step1 used for?
• And two phase commit is used to ensure the atomic in ACID, but how does it ensure the serializability? For examples, if client A sends transaction A and client B sends transaction B to databases simutaniously, then two databases may execute two transactions in different orders. Then two databases may end with non consistent states.

Answer 1

Let me try to explain this using an example. Suppose there is coordinator and two participants named P1 & P2. Now suppose both P1 & P2 creates a transaction to modify a variable A and no other transaction is raised in between, in this case coordinator know that both participants are doing same this coordinator will raise a commit message indicating that both participants can commit and changes will be saved.

Now let's take other example Suppose variable A depends on variable B, now participant P1 raises message to modify variable A and at the same time participant P2 raises message to modify both B & A, in this case coordinator know that participants are going out of sync by executing these commands so master will decline this transaction since it will not serialize.

An assumption about the outcome of transactions, either commit, or abort, can save both messages and logging operations by the participants during the 2PC protocol's execution. For example, when presumed abort, if during system recovery from failure no logged evidence for commit of some transaction is found by the recovery procedure, then it assumes that the transaction has been aborted, and acts accordingly. [Wikipedia]

Answer 2

1. For how to ensure serializable.

   The atomic commit protocol like 2PC only ensures the "atomicity" property, i.e. a cross-shard transaction either commits or aborts on all participants. The "consistency" (in the sense of ACID) is ensured by the concurrency control protocols like 2PL.
   For instance, if you use two-phase locking (2PL) with 2PC, suppose there is a pending transaction T1 that has come to the decision phase of 2PC, then a coming transaction T2 will be blocked at the pre-write phase by the 2PL. In this way, serializability is ensured.

2. For why the transaction ID is needed.

• For implementation, transaction ID serves as an identifier to look up the information (like transaction status, committed, aborted) for a transaction.
• For CC (concurrency control), the transaction ID is sometimes used as a timestamp for the Timestamp-order method to ensure a consistent order of transactions across different shards, or avoid deadlock in techniques like 2PL-wait die.