Designing a commutative replicated data type — mentioned by chalst

Mon, 04 Mar 2019 08:31:22 GMT

This article has led me to Shapiro & Preguiça (2007) https://arxiv.org/pdf/0710.1784.pdf The whole idea that commutativity gives you a better-behaved transition to consistency reminds me of how the theory of patches gives DARCS/Pijul better handling of branches than Git. Cf. Mimram & Giusto (2013) https://arxiv.org/pdf/1311.3903.pdf

Paper and discussion history. A mention is not an endorsement.

Designing a commutative replicated data type — mentioned by pbailis

Fri, 02 Mar 2012 22:52:54 GMT

Right; you need some notion of a total order or commutativity in your update functions. f(A,B) = f(B,A). "Last writer wins" is one example of commutativity, but that isn't often what you want. What you want is something like a "Commutative Replicated Data Type" [1], where you define a commutative function specific to your application. Libraries like StateBox allow you to build CRDTs [2]. In fact, your example of document editing was one of the areas where these ideas first came up. There's also a theorem saying that if your program is "logically monotonic"--that is, if your data only "grows"…

Paper and discussion history. A mention is not an endorsement.

Designing a commutative replicated data type · HackerPapers discussions

Designing a commutative replicated data type — mentioned by chalst

Designing a commutative replicated data type — mentioned by pbailis