Challenge #6b: Totally-Available, Read Uncommitted Transactions

In this challenge, we’ll take our key/value store from the Single-Node Totally-Available Transactions challenge and replicate our writes across all nodes while ensuring a Read Uncommitted consistency model.

Read Uncommitted is an incredibly weak consistency model. It prohibits only a single anomaly:

  • G0 (dirty write): a cycle of transactions linked by write-write dependencies. For instance, transaction T1 appends 1 to key x, transaction T2 appends 2 to x, and T1 appends 3 to x again, producing the value [1, 2, 3].

Specification

Replicate writes from a node that receives a txn message to all other nodes.

Evaluation

Build your Go binary as maelstrom-txn and run it against Maelstrom with the following command:

./maelstrom test -w txn-rw-register --bin ~/go/bin/maelstrom-txn --node-count 2 --concurrency 2n --time-limit 20 --rate 1000 --consistency-models read-uncommitted

Also, ensure that your transactions are totally-available in the face of network partitions:

./maelstrom test -w txn-rw-register --bin ~/go/bin/maelstrom-txn --node-count 2 --concurrency 2n --time-limit 20 --rate 1000 --consistency-models read-uncommitted --availability total --nemesis partition

There’s currently an issue in the Maelstrom checker that prohibits detection of G0 anomalies. Shout out to Ivan Prisyazhnyy for finding the issue!

However, Read Uncommitted allows almost any state to be valid so it’s likely your system is ok and you now have a distributed transaction system ready for the next challenge: Totally-Available, Read Committed Transactions.

If you’re having trouble, jump over to the Fly.io Community forum for help.

  1. Read More About Echo
  2. Read More About Unique ID Generation
  3. Read More About Broadcast
  4. Read More About Grow-Only Counter
  5. Read More About Kafka-Style Log
  6. Read More About Totally-Available Transactions