EventStore: Transactional Operations & Publish to multiple Streams

[Ricardo da Silva]

Hi All

I am considering an implementation where, in response to a command, I would publish two events or more such as;

1. EventType stream, for all consumer generally interested in this type of event across any aggregate

2. CorrelationId Stream, for consumer interested in events of the conversation triggered by a command 

e.g PlaceOrder -> ReduceInventory -> InventoryReduced/InventoryNotReduced -> OrderPlaced/OrdeNotPlaced

However looking at the EventStore API there is now way to publish across multiple streams as a Single Transaction, leaving my system in a possible invalid state should someone pull the plug after only one  these is posted 

Another situation where I would like operations on the EventStore to be transactional would be; once I have processed a command, publish an Event and acknowledge the Command as a transaction. This way the original command will remain un-Acked and redeliverable unless I have a recorded response.

Am I possibly doing it wrong ?

How else might I satisfy these scenarios.

Many thanks

[Greg Young]

"Another situation where I would like operations on the EventStore to
be transactional would be; once I have processed a command, publish an
Event and acknowledge the Command as a transaction. This way the
original command will remain un-Acked and redeliverable unless I have
a recorded response."

use deterministic ids and event store will maintain idempotency thus
you won't have an issue on retry you will write same event id.

"1. EventType stream, for all consumer generally interested in this
type of event across any aggregate

2. CorrelationId Stream, for consumer interested in events of the
conversation triggered by a command
"

see $by_type projection and you can write a projection for correlation id

> --
> 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.
> For more options, visit https://groups.google.com/d/optout.



--
Studying for the Turing test

[Greg Young]

http://code.logos.com/blog/2011/04/generating_a_deterministic_guid.html

so long as the id is the same everything just works. EG say you write
then power goes out before you ack. Message will be redelivered to
another subscriber who will produce the same output (with
deterministic id). Event store will do an idempotent write on the
second write.

Cheers,

Greg

On Tue, Nov 10, 2015 at 2:08 PM, Ricardo Enes da Silva
<ricardoen...@gmail.com> wrote:
> Hi Greg
>
> Nice to hear from you.

> "use deterministic ids and event store will maintain idempotency thus
> you won't have an issue on retry you will write same event id."
>

> By this I think you mean that if the process fails between Publishing an
> event and Acknowledging the Command; the event will be redelivered and
> processed resulting in republishing of the event and acknowledgement of the
> command, but this time the event is ignored by the store, but the command
> Acknowledged. Only problem is how would I do deterministic id giiven the
> event is created in the process. This is my factoring of a Message
>
> class Message{

[Ricardo Enes da Silva]

Hi Greg

Nice to hear from you. 

"use deterministic ids and event store will maintain idempotency thus 
you won't have an issue on retry you will write same event id."

By this I think you mean that; if the process fails between Publishing an event and Acknowledgement of a Command; the event will be redelivered and processed resulting, again, in republishing of the event and acknowledgement of the command, but this time the event is ignored by the store, as this previously succeeded, but the command is Acknowledged. Only problem is how would I implement deterministic id, given the event is created by the process. This is my factoring of a Message

class Message{

    public Guid Id;

    public Guid CorralationId;

    public CausationId;

   

    public Message(Message from){

        Id = Guid.NewGuid();

        CorralationId = from.CorrolationId

        CausationId = from.Id;

    }

}

And this a possible process

class PlaceOrderProcess(){

    void Handle(PlaceOrder message){

        EventStore.Publish(new ReduceInventory(placeOrder))

    }

    void Handle(InvantoryReduced message){

        EvenetStore.Publish(....)

    }

}

Only Causation and Correlation will be the same between multiple executions of of PlaceOrderProcess for the same PlaceOrder message. Should Message.id be a hash of these to make it deterministic instead of Guid.NewGuid() ?

On Tuesday, 10 November 2015 06:29:09 UTC, Ricardo da Silva wrote:

[Greg Young]

See the link I put which includes how to generate deterministic Guids
based on a Guid.