Re: Need help to review a serializability implementation for MySQL Cluster

[Alex Ou]

The section 'Type D of the Serializability Theorem' is up. This starts the second part of the article. In the first part, we've tried to use type B of the Serializability Theorem to interpret conflicts down to field level, hoping conflict-based resource contention would be minimized. Unfortunately, the existence of tuple version in type B implies serialization of its updates, even if two updates write non-overlapping subsets of the tuple; this further implies tuple locks in a lock-based system and isolation rules like First-Committer-Wins in a lock-free system. This is absolutely unnecessary for the writes we've just mentioned, but we can't get around it since this generation of OLTP systems are still tuple-based.

Type C and type D of the Serializability Theorem is based on a tuple-version-free, field-version-only database system we hope future generation of OLTP systems will implement upon. If that could be assumed, the dream of minimizing conflict-based resource contention would become a reality. We'll try to provide a road map to bring this dream to life in the next three sections, with this one being the foundation of the latter two.