These are chat archives for RBMHTechnology/eventuate
Global-scale event sourcing and event collaboration with causal consistency
EventsorcedWriterfor this since I need to handle errors and notify callers about failures, and in a writer I wouldn't have information to reach a caller (in my main
EventsourcedActorI store "responder" objects that I could look up by some connection id and use to send messages to websocket clients).
EventsourcedWriteras well... Or instead allow the writer to ask main actor for some data, like responders...
can event handler be asynchronous?
EventsourcedActor is expected to update local (in memory) state, which can be done synchronously. Async operations usually are realized via event collaboration with other event sourced components. Still, I'd say it would technically be possible (even while not the intended usage): when handling an event the async operation is triggered, and the Future response is used to update the internal state of the
EventsourcedActor. This requires the async operations to be idempotent because they are executed with at-least-once semantics (on restart events might get replayed the were processed already but didn't receive the async result yet).
does it make sense to use event handlers to update read model (external db)
EventsorcedWriter is supposed to do such a job, or alternatively an
EventsorcedProcessor. Events should carry all information that's needed for event processing, I think some time ago there's been a similar discussion here in the chat.
I haven't worked with
EventsourcedWriters until now and therefore know them only roughly - perhaps @krasserm or @volkerstampa can provide more/better advice (both are offline these days).
From EventsourcedWriter example in the docs ... Statements would be executed in parallel and it would break if one depends on another.
Yes, I also think there might be a race condition - if an
AddressUpdated follows a
CustomerCreatedwith the same id then there is no guarantee that the
CustomerCreated is processed by C* before the
AddressUpdated and therefore could overwrite the update (because the
INSERT also sets the address). This could probably be resolved with 1) client side timestamps or 2) grouping statements by customer id and write each group as a batch (would be single partition batches and applied in a single operation by the same C* node). Or a simpler example could be used that doesn't come with such potential issues :-)
future1.flatMap(_ => future2.flatMap(_ => ???))- sequential execution of futures
I can't validate my commands against in memory state
Because I don't know anything/much about your domain and the (business) problem that you're trying to solve it's hard to help more high level. Just talking about implementation details is often not the best solution, especially not if there's no understanding of the underlying domain / context.
sequential execution of futures
Right, that would solve it as well.