[BUG] There seems to be an atomicity issue while rising domain events in Ordering.Api
See original GitHub issueIn the Ordering service we have a ValidateOrAddBuyerAggregateWhenOrderStartedDomainEventHandler
which handles the OrderStartedDomainEvent
, after the Buyer is added or updated a call to SaveEntitiesAsync
is made to dispatch the domain events and save the changes to the database, after that, a call to PublishThroughEventBusAsync
is made. So, if the changes was already saved by calling the SaveEntitiesAsync
method no atomicity will be in place or am I missing something? There is even a bigger problem if a chain of domain events are raised because only the last call to PublishThroughEventBusAsync
will have atomicity between the current handled aggregate and the event.
Issue Analytics
- State:
- Created 5 years ago
- Comments:6
Top Results From Across the Web
distributed transactions - What if domain event failed?
It seems like each event will be in its own transaction scope, which means the system requires to open multiple connection to database...
Read more >May Domain Events handlers lead to new events?
D. Domain Events can trigger other Domain Events but the effects are allways outside the transaction.
Read more >Using Domain Events within a .NET Core Microservice
When using domain events, it makes the concept explicit and part of the Ubiquitous Language; in the eShopOnContainers application, for example, ...
Read more >Event Sourcing is Hard
I worked on a fairly large system using event sourcing, it was a never-ending nightmare. Maybe with better tooling someday it will be...
Read more >Online Event Processing
For almost half a century, ACID transactions (satisfying the properties of atomicity, consistency, isolation, and durability) have been the ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hi @arielmoraes,
This was the chosen solution was, at high level:
Begin a transaction in the TransactionBehaviour: https://github.com/dotnet-architecture/eShopOnContainers/blob/e05a87658128106fef4e628ccb830bc89325d9da/src/Services/Ordering/Ordering.API/Application/Behaviors/TransactionBehaviour.cs#L40
While processing the related commands, add the resulting integration events to a list (an outbox): https://github.com/dotnet-architecture/eShopOnContainers/blob/e05a87658128106fef4e628ccb830bc89325d9da/src/Services/Ordering/Ordering.API/Application/Commands/CreateOrderCommandHandler.cs#L38 There’s a nice detail here, and it’s that the outbox is persisted in the DB, so it’d be easy to implement a “watchdog” microservice that would handle possible failures in the publishing mechanism. This is not implemented in eShopOnContainers.
Commit the transaction for all changes when returning from the behavior pipeline: https://github.com/dotnet-architecture/eShopOnContainers/blob/e05a87658128106fef4e628ccb830bc89325d9da/src/Services/Ordering/Ordering.API/Application/Behaviors/TransactionBehaviour.cs#L44
Publish all integration events in the outbox: https://github.com/dotnet-architecture/eShopOnContainers/blob/e05a87658128106fef4e628ccb830bc89325d9da/src/Services/Ordering/Ordering.API/Application/Behaviors/TransactionBehaviour.cs#L48
This strategy also handles the atomicity of all changes mentioned in issue https://github.com/dotnet-architecture/eShopOnContainers/issues/721
So I’m closing this issue now, but feel free to comment, will reopen if needed.
This issue wasn’t supposed to be closed, wonder who did it 🙄