That system works by giving up interactive transactions. But the foundationdb page claims to have interactive transactions, so it must be doing something else.
Calvin requires all transactions to be executed fully server-side and sacrifices the freedom to non-deterministically abort or reorder transactions on-the-fly during execution. In return, Calvin gets scalability, ACID-compliance, and extremely low-overhead multi-shard transactions over a shared-nothing architecture.
The comments on that post are pretty interesting, too.
FoundationDB transactions are true interactive sessions, unlike distributed databases that require stored procedures. This means that client code can make an iterative series of reads and writes over the network to execute complex transactions.
Comments
http://cs-www.cs.yale.edu/homes/dna/papers/calvin-sigmod12.p...
That system works by giving up interactive transactions. But the foundationdb page claims to have interactive transactions, so it must be doing something else.
From Abadi's blog:
http://dbmsmusings.blogspot.com/2012/05/if-all-these-new-dbm...
Calvin requires all transactions to be executed fully server-side and sacrifices the freedom to non-deterministically abort or reorder transactions on-the-fly during execution. In return, Calvin gets scalability, ACID-compliance, and extremely low-overhead multi-shard transactions over a shared-nothing architecture.
The comments on that post are pretty interesting, too.
And from the foundationdb features page:
http://foundationdb.com/#features
FoundationDB transactions are true interactive sessions, unlike distributed databases that require stored procedures. This means that client code can make an iterative series of reads and writes over the network to execute complex transactions.
Thank you for clarifying. I don't know much about DBs and the Calvin paper is the only one I'm aware of that addressed the commenters question.