These are chat archives for RBMHTechnology/eventuate

13th
Aug 2015
Martin Krasser
@krasserm
Aug 13 2015 05:51
Sorry @ddispaltro , I don't understand your question. Can you please rephrase/elaborate?
Magnus Andersson
@magnusart
Aug 13 2015 07:37
@ddispaltro there is an article by @kasserm that describes the difference in design. From my point of view what is interesting is that Akka Persistence assumes only one active Pesistent Actor per persistence id at any time. Eventuate does not (ie vector clocks and replication), so better fault tolerance but you have to manage conflicts.
Magnus Andersson
@magnusart
Aug 13 2015 07:42
Eventuate also has tools if you want to model your actors as DDD aggregate roots. Where each instance is its own actor. So that would be the encouraged design.
Martin Krasser
@krasserm
Aug 13 2015 11:40
The mentioned article is here. tl;dr PersistentActors in Akka Persistence cannot be replicated and must be singletons. This allows for strong/sequential consistency of actor state but with limited write availability during network partitions. Eventuate additionally supports availability zones (locations) which can be data centers, temporarily connected devices, nodes in a cluster, etc. EventsourcedActors can be replicated across locations and are writable at multiple locations (multi-master). They even remain available for writes even during network partitions (high availability). To make this possible consistency of replicated actors must be relaxed to causal consistency (the strongest consistency that is still compatible with AP from CAP). Event causality is tracked with vector clocks.
Martin Krasser
@krasserm
Aug 13 2015 11:54
Regarding actors as DDD aggregate roots, this is supported by both Akka Persistence and Eventuate. Aggregating events from multiple actors (in views) is part of the design in Eventuate whereas in Akka Persistence this requires special support from journal plugins (coming in Akka 2.4-M3 if I remember correctly). Eventuate's approach to replication even allows aggregating events from actors from different locations.
Martin Krasser
@krasserm
Aug 13 2015 12:03
When choosing AP from CAP, write conflicts cannot be prevented but must be resolved instead. This can be either done automatically or interactively. See the user guide for more details (also introduces Eventuate's CmRDT implementations).
Martin Krasser
@krasserm
Aug 13 2015 12:10
Furthermore, EventsourcedActor replication is just a special case of EventsourcedActor collaboration on a shared (replicated) event log. In that case, EventsourcedActors of different type can collaborate to implement a reliable, distributed business process, for example. Reliable and idempotent event distribution to collaborators is a core feature of a replicated event log.
Dan Di Spaltro
@dispalt
Aug 13 2015 14:11
yeah this all makes lots of sense actually
Dan Di Spaltro
@dispalt
Aug 13 2015 14:26
I basically have an app where say I am tracking user sessions on a website, and I want those sessions to be persistent
which means there's potentially lots and lots of sessions but ideally some of them sharing the same journal so the # of journals doesn't grow exponentially.
so that part I like
I'd prefer dynamic partioning though