It looks like different people use different definitions of partition tolerance; the original meaning was: "The network will be allowed to lose arbitrarily man

It looks like different people use different definitions of partition tolerance; the original meaning was: "The network will be allowed to lose arbitrarily many messages sent from one node to another." Which means that, if you have a network, you have partition tolerance, period. But Stonebraker defines it differently: "If there is a network failure that splits the processing nodes into two groups that cannot talk to each other, then the goal would be to allow processing to continue in both subgroups." Great article here: http://www.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/ http://www.cloudera.com/blog/2010/04/cap-confusion-problems-... As for two-phase commits, I'm not sure what system you've used that requires app knowledge, but (for instance) PostgreSQL does them automagically; you just do PREPARE TRANSACTION and COMMIT PREPARED, and if the transaction fails you need app-level error handling - but presumably you have that error handling even without two-phase commits. Here's an article on Facebook's move to HBase: http://www.facebook.com/note.php?note_id=454991608919 http://www.facebook.com/note.php?note_id=454991608919