Why is two-phase commit considered atomic?

Question

Two phase commit is described as an "atomic commitment protocol". I would expect this to mean that all clients see the state of the world from either before a transaction commits, or after it commits -- with no in-between state. It seems though that it can enter a state where a transaction is partially committed and clients see inconsistent data, breaking atomicity.

Consider the case with two databases, A and B. If there is a partition during the commit phase after A has committed but before B has committed, the transaction is partially committed. A user querying A and B will not see consistent data -- the transaction has committed on A, but B has data from before the commit.

The "Consistent" part of ACID also seems to be broken -- a client querying A and B could see data that violates business rules.

I guess the idea is that the system will eventually be able to recover from this, when the partition is over and the transaction manager instructs B to commit. In the meantime though, the system is in an inconsistent "partially committed" state. Isn't the whole point of atomicity to prevent this? By the time consistency is restored, the damage could already be done.

What property is referred to when two-phase commit is said to be atomic?

Answer 1

Atomic means that either the operation will have some effect or the system will remain at the same state. The 2PC algo works such that first the coordinator asks all the distributed machines to prepare for the transaction. After receiving a Yes it sends in the command to commit the transaction.

If the coordinator receives a success from all the machines only then the transaction is complete otherwise if there is a network outage after that or any other issue then you'll fall into the issue of Two Generals' Problem. Its atomic as much as a distributed system can be.

Consistency can only be achieved with the isolation level. Allow reads or not and allow dirty reads or not.