On Friday, May 9, 2014 5:58:42 PM UTC+2, Paweł Kaczor wrote: > On Friday, May 9, 2014 4:37:16 PM UTC+2, Olger Warnier wrote: > >> On Friday, May 9, 2014 4:29:32 PM UTC+2, Paweł Kaczor wrote: >> >>> On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote: >>> >>>> >>>> >>>> The User actor persist FirstNameChanged, and inside the persist block >>>> it sends a Persistent(FirstNameChanged) message to the AllUsers Processor. >>>> On the query side we have a AllUsersView connected to that processor. When >>>> AllUsersView receives FirstNameChanged it updates the db table. >>>> >>>> To handle lost messages between User and AllUsers you might want to >>>> send an acknowledgement from AllUsers to User, and have a retry mechanism >>>> in User. I would implement that myself in User, but PersistentChannel >>>> might >>>> be an alternative. >>>> >>>> That is the most straight forward solution. The drawback is that >>>> FirstNameChanged is stored twice. >>>> >>> >>> >>> What's wrong with the following (push only) solution (much more simple): >>> User (eventsourced actor) ---- reliable event delivery (Channel) ---> >>> AllUsers (normal actor, updates projection (i.e sql table)) >>> >>> Hi Pawel, >> >> In that way, you need to write your own mechanism to support replay >> towards the views. >> >> Kind regards, >> >> Olger >> >> >>> > Hi Olger, > assuming update of projection is performed synchronously, confirmation > will be sent back to User actor only after projection has been updated > successfully. Events can be redelivered by User actor until they are > confirmed ( > http://doc.akka.io/docs/akka/snapshot/scala/persistence.html#Message_re-delivery) > > So, the "reply towards the view" mechanism is already available, just needs > to be configured (max replies, restarts of User actor) ? > > Best regards, > Pawel >
Hi Pawel, The flow is as follows: Command -> User (event sourced actor) -> Persistent(Event) -> stored in the event store -> View (reads from event store) So the moment your event is persisted in the event store, (eventually) the View will be able to process that event. (it's a pull mechanism) So it depends a bit on your use case what you wish todo here (f.i. you can use the view to build a structure that keeps users with passwords and verify passwords based on that data, your 'sync' call will only use the view and it's data) Just a sample as it all depends on your use case ;) Kind regards, Olger -- >>>>>>>>>> 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
