Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Plausible clocks #68
At the moment, each instance of
However, the majority of use cases are about detecting concurrent updates to replicated EA state at different locations. EA state is usually not replicated within a single location so that concurrent EA state updates within a location are not an issue. This makes causality tracking within a location less important and co-located EAs can share an entry in a vector clock. This means that vector clocks only grow with the number of locations (instead of the usually much larger number of EAs). Consequently, tracking of local time (using a counter) can be moved from EAs to a local log actor. A log actor anyway maintains a local counter which is the sequence number of written events.
EAs at the same location can rely on the fact that they receive all events in the same order. This order is identical with the storage order in a local event log. Should an application still decide to replicate state within a location and concurrent updates are made to these replicas, these updates may be reported as causally related updates which boils down to a last-writer-wins conflict resolution strategy. If this is not an option,
Assuming a small number of locations, this more coarse-grained approach to causality tracking removes the burden from application developers to choose a design and event routing rules that keep vector clock sizes small, yet covering the majority of use cases. We therefore propose to change the causality tracking default to the described alternative.
The approach described above uses less vector clock entries than sources of concurrent activity (EAs) i.e. EAs at the same location share a vector clock entry. This is formalized in plausible clocks.
With plausible clocks, pairs of causally-related events are correctly ordered by the clock, although some concurrent events may also be ordered. In Eventuate, in particular:
Given a function T that maps events to their vector timestamps, for any two events x and y, the following conditions hold (see also
(1) states that plausible clocks assign unique timestamps and (2) is called the weak clock condition. A reported ordering of events x and y means that they are either causally related or concurrent whereas a reported concurrency means that they are actually concurrent:
Plausible clocks can be an enabler for advanced routing capabilities. More fine-grained causality tracking is covered in