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