Does entity state in Lagom REALLY need to be immutable?

The Lagom documentation states that commands, events and entity state need to be immutable.

I have a hard time understanding why entity state needs to be immutable.
I understand that it’s a good practice to prevent state changes circumventing the Lagom framework.

But given that in a specific app access to entity state only happens through Lagom, doesn’t the underlying Akka Actor model prevent any concurrency conflicts that result from mutability?

I think snapshots of the state is saved in the background, possibly in a seperate thread than the actor that may concurrently process command/events modifying the same state instance. Therefore it must be immutable.

This was something we specifically improved in Akka Typed EvenSourcedBehavior, which therefore allow it to be mutable.

1 Like

I’m actually extending EventSourcedBehaviorWithEnforcedReplies. So do I understand you correctly, for example the instance returned by emptyState() may be mutable without the app running into concurrency issues?

Ok, I thought the question was about Lagom’s old PersistentEntity.

For EventSourcedBehaviorWithEnforcedReplies the state (emptyState) can be mutable and you can modify the instance from the event handler. Each entity (EventSourcedBehavior instance) must have it’s own state instance ofc.

Don’t send the mutable state as a reply message, though.

1 Like