{"action":"created","issue":{"url":"https://api.github.com/repos/akka/akka/issues/18033","labels_url":"https://api.github.com/repos/akka/akka/issues/18033/labels{/name}","comments_url":"https://api.github.com/repos/akka/akka/issues/18033/comments","events_url":"https://api.github.com/repos/akka/akka/issues/18033/events","html_url":"https://github.com/akka/akka/pull/18033","id":95815183,"number":18033,"title":"+per #18032 Add onPersistSuccess hook on PersistentActor","user":{"login":"jgordijn","id":210142,"avatar_url":"https://avatars.githubusercontent.com/u/210142?v=3","gravatar_id":"","url":"https://api.github.com/users/jgordijn","html_url":"https://github.com/jgordijn","followers_url":"https://api.github.com/users/jgordijn/followers","following_url":"https://api.github.com/users/jgordijn/following{/other_user}","gists_url":"https://api.github.com/users/jgordijn/gists{/gist_id}","starred_url":"https://api.github.com/users/jgordijn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jgordijn/subscriptions","organizations_url":"https://api.github.com/users/jgordijn/orgs","repos_url":"https://api.github.com/users/jgordijn/repos","events_url":"https://api.github.com/users/jgordijn/events{/privacy}","received_events_url":"https://api.github.com/users/jgordijn/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/akka/akka/labels/t:persistence","name":"t:persistence","color":"CCCCCC"},{"url":"https://api.github.com/repos/akka/akka/labels/tested","name":"tested","color":"d7e102"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":11,"created_at":"2015-07-18T11:05:58Z","updated_at":"2015-07-27T13:57:04Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/akka/akka/pulls/18033","html_url":"https://github.com/akka/akka/pull/18033","diff_url":"https://github.com/akka/akka/pull/18033.diff","patch_url":"https://github.com/akka/akka/pull/18033.patch"},"body":""},"comment":{"url":"https://api.github.com/repos/akka/akka/issues/comments/125215592","html_url":"https://github.com/akka/akka/pull/18033#issuecomment-125215592","issue_url":"https://api.github.com/repos/akka/akka/issues/18033","id":125215592,"user":{"login":"ktoso","id":120979,"avatar_url":"https://avatars.githubusercontent.com/u/120979?v=3","gravatar_id":"","url":"https://api.github.com/users/ktoso","html_url":"https://github.com/ktoso","followers_url":"https://api.github.com/users/ktoso/followers","following_url":"https://api.github.com/users/ktoso/following{/other_user}","gists_url":"https://api.github.com/users/ktoso/gists{/gist_id}","starred_url":"https://api.github.com/users/ktoso/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ktoso/subscriptions","organizations_url":"https://api.github.com/users/ktoso/orgs","repos_url":"https://api.github.com/users/ktoso/repos","events_url":"https://api.github.com/users/ktoso/events{/privacy}","received_events_url":"https://api.github.com/users/ktoso/received_events","type":"User","site_admin":false},"created_at":"2015-07-27T13:57:04Z","updated_at":"2015-07-27T13:57:04Z","body":"> That's why I think the onPersistSuccess should be called first. When the implementer decides to put\r\n> some logic in this hook and maybe change the state, we cannot be sure that the actor is in a consistent\r\n> state when an exception is thrown. That's why I think that the handler from persist should not be called\r\n> in this case.\r\n\r\nWhen an exception is thrown, in any case, we can't assume the actor is in a consistent state I'd say.\r\n\r\n> IMHO the read model should not directly be updated via the events that are emitted in this way.  \r\n> There is no guarantee that you will receive all events. My idea is to have a PersistentView listening and \r\n> issuing Update commands to self to update from the journal. This will give far better guarantees.\r\n\r\nI think it depends – I can imagine an event stream which is \"catching up from the database (events `1 to m`)\" while new events keep being added on the write side. At some point the polling \"has caught up\", and it could consume the event directly from the event-bus. It can know if it can use this event or should use polling based on \"to which seqNr it has reached\" – if the incoming event is `currentSeqNr+1` it can directly push it through the stream (if demand is available on it), otherwise it can drop the event and keep polling once demand arrives. I think this is a very tempting optimisation we could easily implement using the new query side.\r\n\r\n> In effect it is replacing db polling with a signal when to fetch new data.\r\n\r\nYeah, it can be used like that, though directly feeding other systems (pub-sub-ish) also seems like a valid solution to me."}}