Is it possible to manipulate multiple aggregates in one single transaction with event store?
What I mean is: can I write events to multiple streams in one single transaction. If I look at the code (EventStoreConnection and EventStoreTransaction) it doesn’t seem so.
What is the recommended solution?
We could allow this pretty easily in single node but what happens when
you distribute?
If you really want to do it see the 2pc example with
System.Transactions. Start a transaction ... write. Start another
write. Use persistent managed transaction to commit both.
Greg
sometimes you really want to create a Foo and a Bar in the same transaction because users expect it that way. Let me give a sample where I struggle to see how a non transactional solution would look like without introducing a lot of complexity due to the need of/for compensating actions in case of failure and other coordination requirements
A user completes a receipt. What this means is that some physical items are delivered to the facility and go into inventory. When the system acknowledges the users command (to complete the receipt) the user expects that the items have been created in the system. On the other hand the user also expects that nothing has changed in case of failure (the typical atomic behavior…)
I can of course see that one could design the system totally different and the user would be notified that the system is completing the receipt. Everything would happen asynchronously. Once everything is done the user is notified somehow that the task is completed. In case of failure all work that has been done would have to be compensated and the user would have to be notified about the failure. Even if a failure is highly unlikely we still have to account for it and handle it correctly. This seems to be a big effort to me… if on the other hand I could use a transaction… specifically since the task is not a long running process…
Do you create a stream per item in a receipt?
7 марта 2013, в 05:59, Gabriel Schenker [email protected] написал(а):
yes, each item is an aggregate and later during its life cycle will be manipulated individually.
I actually dealt with this exact problem the other day - it turns out the model was missing a “receipt” concept, which asynchronously updated the inventory items later (e.g. using a projections). Szymon’s post from a couple of days back also details this in another domain: http://simon-says-architecture.com/2013/03/07/modelling-accounting-ledger-event-driven
More generally, if you really want to do transactions across streams, the only way to do that currently is via the DTC (which while we don’t support officially, isn’t that hard to put together).
Cheers,
James
This is a strong disadvantage.
DTC is not a good idea, it doesnt make sense to implement CQRS with DTC, because we used CQRS also in order to forget about DTC.
And yes in complex systems it could be a need to store events into many streams in one transaction.