These are chat archives for RBMHTechnology/eventuate
Global-scale event sourcing and event collaboration with causal consistency
target/scala-2.11/src_managed/mainand once as
target/scala-2.11/src_managed/main/compiled_protobuf. To get rid of these errors you can manually remove
target/scala-2.11/src_managed/mainin IntelliJ's project settings from the source folders of all modules that contain protobuf files. However one compile error will remain in IntelliJ regarding an already defined object
EmbeddedCassandra. Currently you will have to ignore this.
@e-Evolution Maybe a quote from the Eventuate documentation answers your question:
Eventuate is not a complete (micro-)service development framework. It focuses more on event-sourcing building blocks and the reliable and causally consistent communication infrastructure between event-sourced services. It leaves service deployment and accessibility an application-level concern. Later versions of Eventuate may extend into these directions though.
@e-Evolution Eventuate supports the development of event-driven and event-sourced micro-services but is not a complete service development framework (yet). See also footnote 1 on the Eventuate Introduction page.
When comparing to Lagom, it makes most sense to compare it with the persistence part of Lagom. Lagom persistence is based on Akka Persistence and you can find a (rather old) comparison here.
On a very high level, event persistence in Akka Persistence is based on a total order of events, which requires application to choose CP of CAP (on the command side). Eventuate supports the same persistence model but additionally support causal event ordering in a replicated event log. This enables applications to choose AP of CAP so that they remain available for writes during networks partitions. More in Architecture.
Persistent entities in Akka Persistence are restricted to be singletons, wheres persistent entities in Eventuate can be replicated (up to global scale e.g. in different data centers) and each replica remains available for writes during network partitions. Consistency across replica state is causal consistency which is the strongest consistency that is still compatible with AP of CAP.
In Eventuate, causality is also preserved for event-based service interactions: event streams consumed by Eventuate services are guaranteed to be causally ordered i.e. a Eventuate service will never see an effect before its cause. Furthermore, Eventuate services can rely on event streams that do not contain duplicates. Causal ordering and de-duplicated event streams can dramatically simplify service logic. Causal ordering is also preserved in Eventuate when aggregating events from (potentially globally) distributed services on the query side of a CQRS application. AFAIK, you cannot have these guarantees for Lagom based applications.
Anyway, I don’t see a fundamental problem supporting Eventuate’s persistence model in Lagom which would allow Lagom services to be replicated across data centers with causal consistency of service state.
Hope that helps!
@krasserm I'm considering the case when same node is added concurrently to a tree. There are several ways to handle it in the paper and one of them probably suites us nicely, namely leave the node with higher vector timestamp. So, when I detect this situation, I look up
Versioned[Edge[A, Id]] from the underlying
versionedEntries (by iteration unfortunately) and then decide what exactly duplicate node to remove by comparing their
vectorTimestamps (one is taken from the "versioned", another comes from
CRDTServiceOps.update method "event" argument.
Does it make sense?
t1 < t2and
t2 < t1evaluate to
t1 conc t2or
t2 conc t1evaluate to
root->b, there should be a traversal order for root's children
b. Will look into implementing ordered tree cause that's what I need anyway
and I can't see other ways for non-ordered tree
you could also use system timestamps and/or emitter ids for automated conflict resolution. But I still didn't read the paper and remain curious for (better) alternatives ;-)
Will look into implementing ordered tree
Which node ordering criteria are used in the paper?
and I can't see other ways for non-ordered tree
you could also require the node id type
A to be an instance of the
Ordering[A] type class (i.e. type parameter
A must have an
Ordering context bound)
It proposes to have Unique Position Identifiers along with nodes. I'm still reading about it though:
A tree with UPI associated to nodes can be built using any sequential editing UPIs. However the WOOT and RGA UPI requires tombstones and thus are more adapted to a 2P CvRDT that contains these tombstones. For 2P CmRDT, the Logoot or Treedoc UPI approaches are more suitable. The complexity of the children order computation depends on the approach used. An example of such construct is .
Orderingis fine though it might be a limitation for the payload
Orderingcontext bound for the payload type, only for the id type
wait, but ids are the same for duplicated nodes, only parent ids differ
yeah, and the addition to the parent node with the lower (or higher) id wins :smiley:
And it's a better starting point then diving into ordered trees
I mean it's easier to implement and have something working
I agree :smiley: