Hi Yvonne,
I’m wondering if this approach also takes concurrency into the account? For example, if 2 commands intending to create the accounts with the same email address arrive at the same time, there’s a chance that both of these commands will pass through the Dispatcher Interceptor validator and when they reach the command handler, 2 AccountCreatedEvents will be raised. One of them will obviously fail to update the lookup table due to a unique constraint violation, but still, I have 2 questions:
- will this failure cause to “roll back” the even from the EventStore? In other words, is this Subscribing Event Processor executed in the same UnitOfWork that the command that originally raised the event?
- even if the lookup table and even store updates participate in the same UnitOfWork, they are still done against different storages. Isn’t this sort of a distributed transactions problem then (which again, can not guarantee the immediate consistency)?
Kind regards,
Beka