While plenty of the article is sensible, the author unfortunately skips very briefly past the one killer situation. It's not enough to say "[Transaction restar

While plenty of the article is sensible, the author unfortunately skips very briefly past the one killer situation. It's not enough to say "[Transaction restart gets a little tricky in nondeterministic systems if some of the volatile state associated with a transaction that was lost during a failure was observed by other machines that did not fail. But there are simple ways to solve this problem that are out of scope for this post.]" Any distributed system has the potential to completely loose some state ... say halfway through a transaction coordinating 2 servers, one bursts into flame and is completely destroyed, along with its non-volatile storage (log files). The other server must rollback (abort) the transaction or we all accept the system is no longer consistent. There are no known ways to resolve this problem. Either accept the risk, or manage it outside the computer system. PS. Don't bother adding extra phases to 2PC, that just delays the decision. The extra phases can't provide any definitive commit/abort answer more than would have been provided by 2PC.