Akka Persistence: Where do the execution of the Command Goes when it is not simply a state update

47 views
Skip to first unread message

Maatary Okouya

unread,
Apr 7, 2016, 12:09:36 AM4/7/16
to Akka User List

Just for clarification: Where do the execution of a command goes, when the execution is not simply a state update (like in most examples found online)

For instance, in my case,

  • The Command is FetchLastHistoryChangeSet which consist in fetching the last history changeset from an external service based on where we left off last time. In other words the time of the newest change of the previous history ChangeSet Fetched.

  • The Event would be HistoryChangeSetFetched(changeSet, time). In correlation to what has been said above, the time should be that of the newest change of the newly history ChangeSet Fetched (as per the command event currently being handled)

Now in all example that i see, it is always: (i) validating the command, then, (ii) persisting the event, and finally (iii) handling the event.

It is in handling the event that i have seen custom code added in addition to the updatestate logic. Where, the custom code is usually added after the update state function. But this custom is most of the time about sending message back to the sender, or broadcasting it to the event bus.

As per my example, it is clear that i need to do quite few operation to actually callPersist(HistoryChangeSetFetched(changeSet, time)). Indeed i need the new changeset, and the time of the newest change of it.

The only way i see it possible is to do the fetch in the validating the command

That is:

case FetchLastHistoryChangeSet => val changetuple = ValidateCommand(FetchLastHistoryChangeSet); persit(HistoryChangeSetFetched(changetuple._1, changetuple._2)) { historyChangeSetFetched =>
  updateState(historyChangeSetFetched)
}

Where the ValidateCommand(FetchLastHistoryChangeSet)

would have as logic, to read last changeSet time (newest change of the changeSet), fetch a new changeset based on it, if it exist, get the time of its newest change, and return the tuple.

My question is, is that how it is supposed to work. Validating command can be something as complex as that ? i.e. actually executing the command ?

Johan Andrén

unread,
Apr 7, 2016, 12:06:47 PM4/7/16
to Akka User List
Hi Maatary,

What you persist should be a domain event and contain all information you need to replay that change, so if you need to fetch data from an external service then it is very likely that the event should contain that data, or the result of a calculation with that data. You do not however update the state using that data (or calculation result) until you have persisted it and know that it will be replayed if the actor is restarted. So in pseudocode:

case FetchLastHistoryChangeSet =>
  val data = otherService()
  // it is ok to read the internal state here, for the calculation
  val resultOfCalculation = calculate(data)
  persist(EventHappened(resultOfCalculation)) { event => 
    // but this is the only place it is ok to change the internal state
    updateState(event.resultOfCalculation) 
  }


I hope this helps
--
Johan Andrén
Akka Team, Lightbend Inc.

Maatary Okouya

unread,
Apr 11, 2016, 8:45:13 AM4/11/16
to akka...@googlegroups.com
Thank you very much. Yes it does. Pretty much what I needed to know.

I believe now the question is more about how to deal with making it non blocking. The call to an external service should not block the thread. Hence will be a future. But to not block on that, one needs some specific code for that right?

Like using become/unbecome stash/unstashAll.

I wish this was somewhat natively supported because it is definitively going to happen all the time. Having to repeat this tricky code everywhere is simply not elegant.

--
>>>>>>>>>> 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 a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/zhTn7huXLKg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages