Shared immutable state between actors

Question

What are the drawbacks of sharing immutable state between actors in a non-clustered system?

It's clear as to why a mutable shared state works against a lot of the guarantees that the actor model provides, but what if that state is immutable? In our case, we have a large dataset which needs to be readily available in memory in order for us to perform operations on it (it's a complex graph which needs to be traversed). For every actor to hydrate the dataset from persistence and hold onto their own copy in memory is quite expensive. A solution to this is to inject a single instance of this data into each actor, thus having them use the same memory space.

Why might it be considered an anti-pattern for actors to share memory objects on the heap?

Answer 1

“State” in this context always implies mutability. Thus, “immutable state” isn't state, it's just immutable data. There is no general problem with sharing immutable data structures between actors. If the data is not changed, there's no useful difference between a shared copy and two separate copies of the data.

However, there might be concerns from a software engineering perspective due to the increased coupling between the actors – but that depends very much on your individual circumstances. For example, the requirement that actors share a memory space might not be appropriate.

Alternative strategies:

• loading the graph lazily instead of fully hydrating the model in each actor
• having a separate actor that provides graph operations
• considering graph loading to be an implementation detail that might internally use a caching/sharing system, even though it appears as immutable to the actors