Mnesia consistency #7215
Mnesia consistency #7215
Conversation
Add causal delivery of messages support with the `mnesia_causal` `gen_server` and vector clock to track causality. Tests are also included for causal delivery.
Add a new API `(a)sync_ec` for eventually consistent operations in addition to the original transactiosn and dirty operations. Implemented as a `mnesia_access` behaviour with `write/3`, `read/3` public functions, etc. The underlying data structure for eventual consistency is a pure operation-based add-wins set. Relevant tests included for eventual consistency API and the pure add-wins set.
|
|
CT Test ResultsTests are running... https://github.com/erlang/otp/actions/runs/4915248509 Results for commit 8d8d887 To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts
// Erlang/OTP Github Action Bot |
|
Wondering if anyone can review this PR? |
I think the OTP team are busy with releasing OTP 26, and your PR is a good addition to the Mnesia, but also a bit complex, for that reason the team trying to avoid to bring into the stdlib. |
Okay, do you recommend keeping waiting until OTP 26 has been released, or maybe do something else? |
As a normal user, I can't suggest more. BTW I admire your work on datalog related stuff, so I think this PR should be a good one. |
Mnesia's default partition tolerance model is to leave it to the programmer during a network partition. Moreover Mnesia only provides two access contexts, dirty and transactions, and lacks intermediate apis that provide consistency. For example, dirty operations might leave the replicas in different states depending on the order of the messages being delivered.
This patch implements a new access context
(a)sync_ecwhich provides eventual consistency when used in conjunction with a new table typepawset. For this patch, the(a)async_ecAPI can handle concurrent addition/deletion in the presence of network delays (while dirty operations might give different results on different replicas). Internally it implements a pure operation-based add-wins set.This is an attempt to fix #7202, although this is likely to require a lot more effort, and this patch is only the first step.