Brandon Holt add type system for weak consistency idea  about 9 years ago

Commit id: 04614ac73aa0f5116918100a091b7295d790abe4

deletions | additions      

       

- difference between a *global* fence (tx committed on all replicas of objects) and *anywhere* or *local* fence (tx committed on *a* replica, so we can get a result, but may not know its global order yet)  - Opportunistic (or optional) transactions  - could have some transaction scheduler that is allowed to drop some txs if they are marked as optional  - example: sampled query of values. any that are "too hard" to read we can just skip. or use weaker semantics (i.e. require only *local* fence) ## Type system to integrate weaker consistency  - We should be able to add weaker consistency (CRDT-like) within data types by just replicating the data structure on multiple shards, then asynchronously communicating updates between them  - is that sufficient to allow people to use these alongside other data types?  - it *may be* (need to investigate) that you would want to make sure that eventually consistent information isn't used in strictly serializable contexts because that might violate the stronger guarantees there  - (it also may be that no one cares, or that it's irrelevant because the programmer already explicitly stated that they're okay with out-of-date values, so what they do with it is their own business  - but: if there is sufficient motivation for it we could make a type system that separates eventually consistent types from strongly consistent ones so that you have to do some explicit cast or synchronization to convert weak to strong  - is there any work in multicore consistency models that does something like this? seems like that's the first place it would show up