Atomic storing and raising of event

[JasonBSteele]

Hi, I've been looking at the examples and have a slight concern that after storing an event, the raising of it could fail resulting in a lack of consistency between the store and the event handlers' materialized views. The sample at https://github.com/yevhen/Streamstone.m-r shows a Publish after a successful Write but not how to deal with the Publish failing:

        try
        {
            Stream.Write(stream, events.Select(ToEventData).ToArray());
        }
        catch (ConcurrencyConflictException e)
        {
            throw new ConcurrencyException();
        }

        foreach (var @event in events)
        {
            // publish current event to the bus for further processing by subscribers
            _publisher.Publish(@event);
        }

Is there a case for some how making the Stream.Write and the Publish transactional/atomic? Or can you suggest a way of implementing this in our own code?

[yevhen]

Hi! No, you can't have transaction between azure table and arbitrary storage (projection store). If you absolutely need this you should take a look somewhere else. SQL can give you this (Marten, SQLStreamStore, etc). The alternative could be smth like CosmosDB which support transactions between multiple models (I've never tried it but it's in the docs). To have eventually consistent update of projections you can first write an event to a global stream and only then to an aggregate. Then you can update projections from that global stream.