> > That would mean that developing such an application could be quite > different from developing a local application, > where state is spread over many objects. (Or rather, the only way to > change state in another object would be that > the other object is an Actor as well and it receives an event that is > raised. But what if it does not receive the event > during replay? Wouldn't that corrupt the overall state of the application?) >
I'm not sure what better minds think of this, but I've avoided raising events for other actors or systems to consume during restart. The classic is the "paid" event for an order -- it's essential for the order to realize the amount due's been paid as it's recovering, but if it emits the "paid" event again, will something else count the order as having been paid twice? I've taken the approach that if an actor needs to recover state after a restart, it's responsible for that. So I have a case where a CQRS pattern has both the "command" actors and the "query" actor doing even persistence. The "query" actor replays all the events it's seen from the "command" actors, so there's no double-counting. -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
