Either there was something more consistent than sarcasm or we did not (completely) read the same article.

Yang goes as far as both:
- Giving due value to Abadi's idea;
- But pointing its limitations in terms of synchronization / protocols issues.

Also, my interpretation was always that Abadi is trying to go beyond VoltDB and H-Store and his comments seem to confirm this:
http://dbmsmusings.blogspot.com/2010/08/problems-with-acid-and-how-to-fix-them.html?showComment=1283539133123#c8188516063804926692


Cheers,
Paulo Gaspar

On 2010-09-07, at 23:36, Ann W. Harrison wrote:

> On 9/7/2010 1:19 PM, Paulo Gaspar wrote:
> > There is already a brilliant reply / rebuttal:
> >
> > http://yz.mit.edu/wp/infrequently-asked-questions-on-deterministic-distributed-transaction-management/
> >
> >
>
> Well, that's a bit more sarcasm than I normally project,
> but, even excluding the language limitations in VoltDB,
> here are the practical restrictions on deterministic
> transaction management.
>
> First, all transactions are predefined. A transaction is
> a single stored procedure (Java) with one set of input values
> and one set of output values. The possible number of output
> values is large, but not infinite. There can be no user
> interaction during a transaction.
>
> Second, there is no disk. Durability comes from having
> some number of synchronous replicas. Each core has a
> dedicated section of memory which holds its partition.
> If a partition grows beyond that section of memory, the
> whole database must be dumped to disk, repartioned, and
> reloaded.
>
> Third, each partition has one master where all writes must
> occur and some number of replicas that can be used only
> for read-only transactions. To continue safely after a
> failure, there must be at least copies of each partition.
> Two of cores are unable to run read/write transactions.
> Every read/write transaction blocks all other access to the
> partition it's running on.
>
> Fourth, a transaction that spans partitions locks all
> the partitions it touches.
>
> So, think of life with out direct SQL, without suspend
> in procedures, without execute block, and with the total
> size of the database limited by memory.
>
> It runs DBT2 like a bat out of hell....
>
> Cheers,
>
> Ann
>



[Non-text portions of this message have been removed]