Thanks for your reply Sean.
I have read about the proposed changes of the query side in akka
persistence and I think you are right regarding the use of views in this
case. I'm going to have go at using a separate read store to keep track of
the events processed as you suggested.
Rune
On Friday, September 12, 2014 4:09:50 PM UTC+2, Sean Walsh wrote:
>
> Rune,
>
> I wouldn't knock yourself out using the persistent views (as I did, even
> going so far as creating dynamic views upon aggregate creation) because the
> design is undergoing some big changes. In my opinion you'd be better off
> having an actor listening for the events on behalf of all persistent
> entities and updating its own read store to determine whether a particular
> user has been notified on that particular event.
>
> Use at least once or at most once delivery semantics depending on your
> requirements. In my opinion this design will map better into the future of
> Akka read side projection support.
>
> On Thursday, September 11, 2014 3:05:25 PM UTC-4, Rune Barikmo wrote:
>>
>> Hi guys,
>>
>> I'm building an event sourced application using akka persistence and I'm
>> using a 1:1 setup with one persistent actor per aggregate.
>> The next thing I want to implement is a notification service that
>> consumes the events generated by the aggregate and notifies the users when
>> specific state changes has occurred.
>> My first attempt at this was to create a PersistentView that receives the
>> events and update an in memory state based on some of these events. When a
>> new event arrives, it will update the local actor state and send a
>> notification to the user if a certain criteria has been met. This works,
>> but the problem occurs during recovery since all the events will be
>> replayed to the view which would cause the same notification to be
>> redelivered to the user. I don't see a way of differentiating between
>> recovery messages and normal messages received by the view.
>>
>> So to solve this I definitely need to persist the events that has been
>> processed. I could of course implement this logic in the persistent
>> aggregate actor itself since it has all the state information needed, but
>> ideally I would like to decouple this logic from the aggregate.
>>
>> Maybe I could still use a persistent view, but I would need to store the
>> events in some persistent storage so that I can keep track of which events
>> has been processed. Or should I just use another persistent actor for this
>> notification service? If so, how should I update this actor? Using a view?
>> :)
>>
>> Essentially what I need is:
>> - After recovery is completed, initialize notification service (or other
>> services subscribing to events) with current state
>> - Subsequent events generated by aggregate is forwarded to this service
>>
>> How about this solution?:
>> 1) Notification service registers it self with the aggregate by sending a
>> message when it starts
>> aggregate ! RegisterSubscriber
>> 2) Aggregate keeps track of all the listeners and persists these to the
>> journal
>> 3) Aggregate: After RecoveryCompleted is received, send InitState(state:
>> State) or InitEvents(events: List[Event]) to listeners
>> listeners foreach { ref => ref ! InitState(state) }
>> 4) Aggregate: during normal operation - forward events to listeners after
>> persisting event. Perhaps using AtLeastOnceDelivery to make sure we don't
>> loose any notifications
>>
>> What do you think? Essentially I'm just looking to get some advice on how
>> to best solve this. Any suggestions are appreciated.
>>
>> Cheers
>> Rune
>>
>>
>>
>>
>>
>>
--
>>>>>>>>>> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
