paulruizendaal wrote:

>
>
>> The major thrust of the theory section is that serializability is stronger than necessary to ensure consistency, but also that consistency needs a more rigorous definition.
>>
>
> Perhaps such consistency is best defined by specifying the permitted permutations of transaction order for each "observer":
> - total ordering of conflicting write transactions
> - causal ordering of non-conflicting write transactions
> - fifo ordering of read transactions
>

I don't see the point. The database isn't observable except through the
lens of a transaction. If each transaction is consistent and conforms
to declared rules of database consistency, the database is consistent.

An algebra of transaction logs by class was the basis of SDD-1, a
seminal two decade old study in distributed database. The bottom line
is that an unclassed transaction screwed up the algebra requiring
everything to be lock. See Shipman, Bernstein, Goodman, et al.

I have never heard a theoretical justification of serializability as the
test of database consistency. I think it seemed like a good idea at the
time and almost nobody since (myself excluded, of course) questioned
it. Just like nobody questions the merits of varchar or tiny ints.

>
>> The 25 year fixation on serializability rather than consistency has lead to an unnecessarily constrained view of the range of database implementations.
>>
>
> Agree. If I were in the audience I would ask if the above set of constraints is the theoretical minimum still resulting in "consistency for each observer" and in identical state after quiescing ?
>

Identical isn't required. Equivalent is. Unobservable internal states
can be different, but as long as each gives the same answers, all is good.

>

--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376



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