In order to reconcile ACID with CAP, this defines a weakened form of ACID to mean whatever-some-databases-currently marketed-as-ACID-compliant-support in order to say that you can still offer effective ACID compliance and still choose CA over partition tolerance (in the <a href="http://codahale.com/you-cant-sacrifice-partition-tolerance/" rel="nofollow">http://codahale.com/you-cant-sacrifice-partition-tolerance/</a> sense). For a lot of applications, the weakened isolation guarantees aren't, or shouldn't be, negotiable (if you try to sneak by without them, they'll cause data integrity issues at scale).<p>Not saying that the solution doesn't provide a valuable framework for building robust applications that can overcome those issues (necessarily pushing some of that complexity up the stack to the application developer), but the marketing seems a little bit suspicious?<p>Edited to add: In fairness, the article doesn't actually claim to have evaded CAP - it recognizes that HAT is a compromise. But I believe it's easy to understate the practical problems with non-serializable transactions. It becomes impossible to prevent duplicate transactions from being created on the split-brain nodes. In banking, for instance, this would be a Bad Thing, and lead to potentially hairy application-specific mop up when the nodes resync.
Interesting paper, I hope to see a follow on that actually describes the algorithm in full. As written, it doesn't cover the failure recovery, data-drift and timeout cases.<p>Also maybe you could speak to a few constraints:
- missing updates
- unique index<p>and outline your thoughts as to how an application developer might avoid pitfalls. Most applications I have seen tend to require/run in to these issues.