The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

402361 (3) [Avatar] Offline
#1
It is not more safe to update state as a callback of eventLog.put?
What if eventLog.put returns failed Future?

Thanks
Debasish Ghosh (116) [Avatar] Offline
#2
I am not sure I understand the question. Instead of guessing, will u please write in some more details .. Thanks.
402361 (3) [Avatar] Offline
#3
I'm referring to this snippet in listing 8.7

eventLog.put(no, c)
onClose(updateState(c, currentState)(no))


In FP, we don't throw exceptions. So,
eventLog.put(no, c)
might fail silently in this case and we end up updating the state for an event that has not been journaled. It is not better to update the state using a callback to eventLog.put?

Thanks
Debasish Ghosh (116) [Avatar] Offline
#4
Using a callback can be an option. But usually what happens is that in a production ready event log implementation, the underlying library takes care of failure management by offering replication, local writes etc. thereby taking the load off the application developer. I have not discussed details of such distributed event logging mechanism - take a look at Eventuate (http://rbmhtechnology.github.io/eventuate/overview.html) for a sample. Especially http://rbmhtechnology.github.io/eventuate/overview.html#event-log.

HTH.