Concurrent Commands, Interleaved Events

[Peter Michaux]

A command generates multiple events. If the command runs in two concurrent threads, the events saved to the event store could be interleaved. Is it a common feature of event stores to lock the events table/file so that all the events from a single command are saved in a contiguous block?

Peter

[João Bragança]

How can a command run in two concurrent threads?

On Tue, Jun 12, 2018 at 9:48 AM Peter Michaux <peterm...@gmail.com> wrote:

A command generates multiple events. If the command runs in two concurrent threads, the events saved to the event store could be interleaved. Is it a common feature of event stores to lock the events table/file so that all the events from a single command are saved in a contiguous block?

Peter

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

--

Sent from my regular computer

http://twitter.com/thefringeninja

http://www.thefringeninja.com/

[Peter Michaux]

I meant two instances of the same Command class. One instance running in one thread. The other instance running in the other thread.

Peter

[Danil Suits]

Most event store implementations that I have seen (more than one, fewer than ten) support contiguous writes of multiple events to a single "document".

For instance

Task<WriteResult> AppendToStreamAsync(string stream, long expectedVersion, params EventData[] events)

writes all of the events, or none; when you query the stream after a successful write, you will find all of the events together.  That guarantee seems to hold whether you enable the optimistic concurrency checks by specifying an expected stream position, or if you disable the check via ExpectedVersion.ANY

Writes to different "documents" might as well be writes to different hosts; I've never seen any sort of deterministic ordering guarantees across multiple documents.

Document tends to be implementation defined.  EventStore treats each identified stream as a separate document, and as far as I know offers no guarantees to writes to multiple streams.  Event stores on RDBMS platforms may or may not support an update of multiple streams in the same "transaction".