3 ms·
This looks very interesting, but I still don't get how do they avoid concurrency on the switch: "The switch cannot be concurrently accessed – reads and writes
by saganus 11y ago
This looks very interesting, but I still don't get how do they avoid concurrency on the switch:
"The switch cannot be concurrently accessed – reads and writes of the switch are strictly ordered". If not with a lock file, maybe a log-based architecture?
- nicwolff 11y agoThe detail section says "by a combination of raft and our underlying storage engine"
- mrtracy 11y agoPost author here! The on disk part of the "switch", our transaction record, can only be accessed internally. There are only a small number of operations to perform on it - create it, read its value, and a small number of deterministic "read-then-write" operations. For example, in the case of an "abandoned" transaction, a later transaction may want to read the abandoned transaction record, see if it is still "pending", and then mark it as "aborted" if it is. Our runtime orders all such operations on the same record so that they are completely sequential - that is, even for a "read-then-write" operation, it must completely finish before any other operation can occur on that key. This is done using basic runtime synchronization primitives (mutexes, channels, etc).
- saganus 11y agoThanks for the detailed explanation. Looking forward for the next post!