3 ms·
“Exactly one” is a hard concept to get right. How do they ensure that exactly one instance of an actor is alive at once, without sacrificing latency of actor st
by newobj 4y ago
“Exactly one” is a hard concept to get right. How do they ensure that exactly one instance of an actor is alive at once, without sacrificing latency of actor start and/or while tolerating network partitions?
- ackfoobar 4y agohttps://proto.actor/docs/cluster-partitions/#multiple-activations https://proto.actor/docs/cluster-partitions/#multiple-activa... > This can be prevented by persisting state in a database with some form of CAS operations, e.g. Couchbase.
- mirekrusin 4y agoThat's still "at most one" – ie. even though state of database itself is "exactly one" (...can "hold the lock") – the fact that actor thread is remote, it means it can be partitioned/starve the rest of the system. "Exactly once" can be achieved with "at least once" + _local_, reliable state where you can resolve/ignore duplicates. But if that "local" state is actually "remote" – well, then you loose this guarantee (because you can be arbitrarily partitioned from that state so you're in square one again).