On 9/7/2010 6:36 PM, Ann W. Harrison wrote:

>
> It runs DBT2 like a bat out of hell....
>

Jim points out that it's not really DBT2, its a version that does
nearly the same thing, but works better with the deterministic model.

Here's an interesting quote from the paper.

<quote>
4.2 Difficult transaction classes

It isn't necessarily possible for every transaction to request
locks on every record it accesses immediately upon entering
the system. Consider the transaction

U(x):
y <- read(x)
write(y)

where x in a record's primary key, y is a local variable, and
write(y) updates the record whose primary key is y.

Immediately upon entering the system, it is clearly impossible
for a transaction of type U to request all of its locks (without
locking y's entire table), since the execution engine has no way
of determining y's value without performing a read of record x.
We term such transactions dependent transactions. Our scheme
addresses the problem of dependent transactions by decomposing
them into multiple transactions, all of which but the last work
toward discovering the full read/write set so that the final one
can begin execution knowing everything it has to access. For
example, U can be decomposed into the transactions

U1(x):
y <- read(x)
newtxnrequest(U2(x, y))

and
U2(x,y):
y'<- read(x)
if (y' <> y)
newtxnrequest(U2(x,y'))
abort()
else
write(y)

U2 is no included in the ordered transaction batches that are
dispatched from the preprocessor to the replicas until the
result of U1 is returned to the preprocessor (any number of
transactions can be run in the meantime).

</quote>

Picture your typical transaction. Picture that transaction split
into "non-dependent" transactions. Picture running them mixed
with other transactions, and rerunning the set whenever anything
changes.

Different world.


Cheers,

Ann