Commit Protocol

Due to the distributed nature of NuoDB, a form of two-phase commit is required since multiple SMs are typically being asked to commit the same data in parallel.

For this reason the diagram in /architecture/data-model/replication.adoc#replicating-changes is over-simplified.

Complete Write Data Flow
Figure 1. Complete Write Data Flow

  1. App sends SQL to TE1.

  2. Modified atom diffs sent to SMs, and any TEs (TE2) with the atom cached, as a pre-commit message.

    • SMs copy the change into their journal.

  3. TE1 waits for acknowledgements from SMs.

  4. TE1 tells all engines (TE2, SM1, SM2) to commit.

    • TE2 updates its cached copy.

    • Each SM adds a commit message to their Journal.

    • TE1 acknowledges App.

Because the messages in the journal have an associated COMMIT message, the changes will be used to update the archive. If, for any reason, the COMMIT is never received, the changes in the journal are ignored (rolled-back).

In the documentation, this is referred to as the Safe Commit Protocol.

Other commit protocols existed in NuoDB, to reduce ACK wait times in exchange for less consistency, but are now deprecated and should not be used. They are replaced by Asynchronous SMs instead.