These are chat archives for RBMHTechnology/eventuate

Oct 2016
Martin Krasser
Oct 17 2016 08:16
@gabrielgiussi RBMHTechnology/eventuate#328
Oct 17 2016 17:00

That was fast!
In another subject, I have a couple of questions for you. When you compare Akka persistence with Eventuate you say that (1)

Event-sourced actors in #akka-persistence choose CP from CAP whereas those in Eventuate choose AP

As I see it, akka persistence isn't CP by its own. It needs Cluster Sharding, doesn't? Documentation says:

In this context sharding means that actors with an identifier, so called entities, can be automatically distributed across multiple nodes in the cluster. Each entity actor runs only at one place, and messages can be sent to the entity without requiring the sender to know the location of the destination actor.

And (2) you say:

Eventuate's EventsourcedActor can be operated as global singleton too, but can additionally be replicated, relaxing strong consistency to causal consistency.

How we could prevent the case where we end up with two instances with the same aggregateId running in different locations?

Srepfler Srdan
Oct 17 2016 18:03
how is the aggregate id created?
Bartosz Sypytkowski
Oct 17 2016 20:07
@gabrielgiussi you can use eventuate with cluster sharding if you need. Casual consistency means, that you don't need to prevent creating two instances of the same aggregate, because the state changes on those instances will be replicated to one another and eventually state itself will be convergent in both instances
@schrepfler it's not created. It's up to you to decide how to provide it
Srepfler Srdan
Oct 17 2016 20:09
so, if it’s like other ddd frameworks
typically one generates it with some UUID generator
Bartosz Sypytkowski
Oct 17 2016 20:10
Srepfler Srdan
Oct 17 2016 20:11
that’s the guarantee
just make sure the entropy pools of your servers are different and you don’t have to worry about it
Oct 17 2016 23:14

@Horusiath IMHO that's not what causal consistency means. Causal consistency means that the delivery of the events in each location honours the happen before relation between the events. But it stills let you deal with concurrent updates (those not captured by the causal relation between events). For dealing with concurrent updates in eventuate we could opt between:

However, I understand the AP nature of Eventuate, my doubt was about the possibility of use Eventuate as CP. I think we need akka cluster sharding like you say, but I get confused with the @krasserm phrase:

Eventuate's EventsourcedActor can be operated as global singleton too

@schrepfler Unique key generation doesn't ensures unique Actor across locations.