Concurrency problems with state update can lead to membership data loss

[cmeiklejohn]

The attempt_join process uses the externally exported update_state function to write the state back to the ETS table; however, a race condition can occur where the state in the ETS table has changed which will be overwritten when persisted back to the ETS table.

What really needs to happen is that attempt_join needs to submit it's own changes; the metadata manager needs to act in serial and compute the merge, or join, itself before binding the state change. This is the only safe way to compute this join and is how Lasp deals with concurrent edits to the same CRDT at a single replica.

[cmeiklejohn]

I've got a patched version of this in the Lasp fork of Plumtree.

[cmeiklejohn]

Addressed by #23.