search

RBMHTechnology / eventuate

Global-scale event sourcing and event collaboration with causal consistency (This project is in maintenance mode. Only critical bugs will be fixed, but there is no more feature development.).
http://rbmhtechnology.github.io/eventuate/
Apache License 2.0
708 stars 99 forks source link

Replay from application-defined sequence number #302

Closed krasserm closed 8 years ago

krasserm commented 8 years ago

See https://github.com/RBMHTechnology/eventuate/pull/300#issuecomment-241689257

magro commented 8 years ago

A general issue might be that the application might load the sequence number from some backend asynchronously. This way it would be forced to await the result. Because this is only done once on startup and therfore might be acceptable, but I still wanted to point at it.

magro commented 8 years ago

Please forget my comment, the application can load the sequence number asynchronously and start the actor once it's loaded / on complete.

magro commented 8 years ago

And just for completeness, I was referring to commit 1703405 :-)

danbim commented 8 years ago

Just for completeness:

When implementing #300 my intention was to make sure that all business logic (and also all the logic to restore an actors state) should be encapsulated within the actor itself. If we load the sequence number asynchronously and pass that into the actor as parameter we would have to externalize that logic. From an application point-of-view I think this is less optimal.

However, I could live with the synchronous version (which is undoubtedly more beautiful / less error-prone) from a framework perspective. Also I guess one could co-locate the loadSequenceNr logic with the business / actor logic by e.g., putting it into the companion object so my initial intention would be met anyways.

Another argument that favours the synchronous version is that error handling for loadSequenceNr is simpler as with the asynchronous version.

So, synchronous version fine with me!

volkerstampa commented 8 years ago

If the sequence number is loaded from some backend, this is not only done once at startup, but each time the actor restarts, i.e. each time an event-replay is required, right? So it depends on the application logic if this should be done frequently or just once at application startup.

krasserm commented 8 years ago

Alternatively (to reading from somewhere), a supervisor stops the actor on exception and a watcher creates a new actor with another sequence number as constructor argument on receiving the termination signal.